Software Engineers sometimes, struggle with the understanding the strong integrity and the high standards of our trade and face multiple questions over the course of their engineering career.
Without right answers to those common questions and proper career mentorship, they feel dejected and eventually, give up on this noble trade to pursue business or other arts.
This article is a humble attempt to collate all the common problems and provide answers, guided by strong sense of integrity and high standards of this noble profession to guide the upcoming generation of software engineers.
Note that this will be a running document, which will be updated regularly based on new popping problems faced by the next upcoming generation of engineers, so that they can provide their best service to their organization, community and to themselves.
To give real service you must add something which cannot be bought or measured with money, and that is sincerity and integrity. Douglas Adams
Learning to code is like riding a bike.
You get on the bike, but you’re scared to put feet on the pedals because you might end up falling. You push the pedals forward, but then you fall over because you weren’t pedalling fast enough. To ride the bike, you need a leap of faith — you need to believe you can do it so you can start pedalling in earnest.
When you get a coding task, you don’t know how to solve it. But you need to believe you can solve it, so you don’t give up and say “this is beyond my abilities.” You need that leap of faith to stay in your seat and work towards a solution.
This faith isn’t something you’re born with. It’s something you earn. You earn trust in yourself by solving more and more problems, of larger and larger scope. And as you start trusting yourself, others learn to trust you.
It’s better to succeed together than to fail alone.
Example 1:
Ted was a junior engineer new to the team. Whenever Ted was stuck on something, he asked a senior engineer. Thanks to their help, Ted completed his projects well ahead of schedule. He also learned a lot from his peers, so he started asking for help less often, and became an expert in his domain.
Ned was also new. He was afraid to bother people, and wanted to look smart. So he saved all his questions for his weekly 1:1, if he asked them at all. He spent weeks being stuck on minor things, and shipped his first project much later than expected.
Who got the promo, Ted or Ned?
Example 2:
Jan was given a project. His manager said it was hard, and asked if he needed help with it. Jan said it was easy, that he could do it himself in 3 months.
Three months later, he hadn’t shipped anything. Despite being a solid coder, he had trouble getting his code reviewed, since no one else was working on the project with him. He also made a few design mistakes, since he was fairly junior, and no one helped with the design.
Next half, the project was given to Nan. Nan had ten years of experience and immediately asked for a team of three people. The team shipped in three months, with much glory and fanfare.
Guess who became the team’s tech lead?
The more you help people, the stronger you get.
Example 3:
Sam was gunning for a promo, and was laser-focused on shipping his projects. If someone asked him for help, he wouldn’t respond very quickly, since he was busy with his own stuff.
Sam shipped his projects with adequate speed, but spent a lot of time debugging. People didn’t really help him debug, and a lot of bugs came from code he didn’t know very well, since it wasn’t directly related to his project.
Pam had projects, but wanted to help other people ship their projects. She frequently helped other people find bugs in their work, and was the first to jump on issues that impacted production.
Every time she helped someone fix a bug, she learned about the system they were working on. She helped a lot of people, so she had knowledge of almost everything. Her projects didn’t take as long, because her knowledge helped her find bugs faster. She also had a lot of friends, which helped her ship code faster.
I’m not going to say “don’t be Sam.” Sam’s a fine engineer, every team needs a few Sams. But it’s better to be Pam.
Be the computer.
Computers context-switch.
It runs Spotify in the background while waiting for you to move the mouse.
Great programmers write code while waiting for other code to be reviewed. If they are blocked on their first project, they ask for a second project.
Computers have a cache.
The most recent work it was doing goes into a special part of their memory, so that it can access it quickly next time it needs it.
Great programmers keep multiple projects in their mind at a time, so if they suddenly need to work on Project #3, they can start right away instead of trying to remember what they were doing.
Computers schedule tasks.
Many humans use the Last-In-First-Out method of scheduling — the task they do first is the task that was most recently given to them. The most efficient humans sort the tasks by priority and/or urgency, and work on the highest-priority tasks first.
Computers network.
It provides you the solution or what you are looking from other computer servers through the internet.
Many new programmers are afraid to ask questions or figure out the solution for their problems and just sit on the tasks. The right approach should be to seek out solutions locally within the team across peers/organization or even, globally in the developer community, say StackOverflow or Google and thus, build your own network.
Computers self-update.
Computers can update themselves with patches over the network.
The best programmers always keep learning, keep them up-to-date with the latest developments in technology, understand its merits and demerits and hence, know what tools to pick for what.
Computers have a nice user interface.
Programmers with good social skills are easier to interact with.
Evolve into supercomputers with more nodes and cores.
The programmers who are 10x are the ones, who have a large impact and they create those impacts by rallying other developers to initiatives, delegating them tasks, guiding and mentoring them, and providing them purpose. At this point, you are not just good but a 10x Great Software Engineer.
You become a 10x engineer by making ten engineers twice as productive. You unblock other engineers and help them fix their most difficult issues.
Examples
● The whole system is broken and no one can do any work. Every hour the system is broken is 10 wasted hours of engineering time. You fix the system in 1 hour. You are a 10x engineer.
● Your friend writes a diff with a bug in it. You review the code and find the bug before he puts it in production. If it had made it to production, it would have cost 5 hours of time to fix, but you found it in 15 minutes. You are a 20x engineer.
● Your friend would have spent three days fixing a bug. Instead, he asks you for help, and you proactively, solve it in 1 hour. Your 1 hour saved the other guy 24 business hours. You are a 24x engineer.
● Your team’s code has no unit tests. You add a bunch of unit tests to the code. Other people copy the style of your code, so soon there are hundreds of unit tests. Now bugs that took days to catch are being found immediately. You are a 50x engineer.
● Your friend is doing a project. You learn that someone else on another team is doing exactly the same thing. You take them both out for ice cream, and they find a way to work together. They save 3 months of development time. You are a 100x engineer.
● Your friend is unhappy and thinking about leaving the company. You coach him and talk him through his problems. He becomes happier and decides to stay. Replacing him and ramping up a new team member would have taken 6 months. You are a 500x engineer.
In tech, everyone is a software engineer but with a different x.
Team Leads/Architects/Engineering Managers also have different and higher levels of X impact and responsibility.
Giving the mentees tasks that are very well-documented. It should be clear which part of the code they should change, and how they should test their changes. Ideally, you can link to an example diff where you’ve documented how you tested your change.
Introducing them to other people on the team or organization and telling them what each person is working on. Usually, new hires are self-conscious about bugging one person too much, so if they have three or four “friends” they will load balance their questions. It also helps them feel welcome on the team.
Important, Never directly solving problems for them. When a mentee brings you an issue, the expert’s natural reaction is to fix the bug for them. But it’s much more educational if you tell them how you would fix the bug so that they know how to do it themselves in the future.
Situation 1:
Mentee: “I don’t think I have access to this service.”
Bad mentor: “Sorry to hear that, let me send an email to IT and get that sorted out for you.”
Good mentor: “IT is in charge of this, can you send an email to […] asking for permissions?Thanks!”
Situation 2:
Mentee: “I’m lost, can you help me debug my code?”
Bad mentor: “Sure thing, can you send me your code? (2 hours later) Okay I found your issue, you were doing X but you should do Y instead.”
Good mentor: “What have you tried so far? Have you tried running the code locally and going through it with a debugger? OMG you’re gonna love this, debuggers are the bees’ knees. Here’s the wiki about how to set up the debugger and run our service locally — let me know what you find!”
There is a very thin line between hand-holding and spoon-feeding. Spoon feed an infant, but hand hold an adult.
As soon as Jane joined my team, she was assigned the messiest part of our codebase. It wasn’t actively maintained, no one on our team understood it, and there was almost no documentation. Jane didn’t complain about this. She fixed things.
She cleaned up unused code paths. She added unit tests. She removed old experiment code that hadn’t been touched in years. She documented the whole system and became the local expert on that code. Now the code is better because she made it better.
Do you want to be Jane, or do you want to sit around complaining about bad documentation? I know which person I would rather have as my teammate.
Always follow the boy scout rule:
Always leave the campground cleaner than you found it.
If you find a mess on the ground, you clean it up regardless of who might have made it. You intentionally improve the environment for the next group of campers.
Just yesterday, I proposed an idea, and Very Talented Victor weighed in on it.
Victor: “Is this the right approach? Do you think we should adjust X instead?”
Me: “That’s a good thought. Let me run another analysis, and check if it’s X or Y that makes the difference.”
After running the queries, I saw something super interesting in the plots. With the new plots, my idea became a lot more compelling!
When I presented the idea at the team meeting, people were way more interested than they were before — all because I learned from Victor’s feedback.
Always encourage questions. Even stupid ones.
Here’s a secret:
You can’t be productive without other people.
It’s hard to be a great engineer if you don’t gel well in the team.
The Attitude.
Consider three engineers: Jim, John, and Jane.
Jim comes to work at 11:30 and leaves at 4:30. He doesn’t care much about his job, so he writes just enough code to avoid getting fired. The code he does write is sloppily hacked together and poorly tested. He never writes documentation, because that would be too much effort. When he goes on-call, he ignores most alerts, because they’re probably not important anyway.
John is very ambitious, and really wants to do a good job, so he can get promoted. In fact, he refuses to work on any project that won’t get him promoted, and tells his manager to give those projects to other teammates. When John gets assigned a task that won’t get him promoted, he usually ignores it, or gives it to someone else.
John is fairly senior, so junior engineers often seek out his expertise. When someone asks John for help, he first evaluates how important the person is. If the person isn’t going to write him peer feedback, John is too busy to reply to their messages.
Jane just graduated college, and hasn’t built a lot of software in the past. But she cares deeply about the quality of her work. Her code is impeccably tested, and flush with comments. She didn’t know what a move constructor was, or how to declare a variable “const”, but she quickly picked that up in her first few code reviews.
Jane is happy to work on any project her manager assigns her. She figures if the manager gives her a project, that must be what’s best for the team. Sometimes Jane is given tasks that belong to other teams and takes those tasks as seriously as her own engineering work (because other teams are doing important things too).
When other engineers ask Jane questions, she sits with them for twenty or thirty minutes and helps them debug their issue, even if she doesn’t know the answer off the top of her head.
Be Jane. Don’t be John or Jim.
Being a great engineer is all about having the right attitude.
So, to succeed as a software engineer, all it takes is the right attitude of sincerity and integrity towards the service, not a moonshot. After all, software engineers are indeed, artists but with more responsibility towards their organization, community and to themselves with this gift.
Remember, Software Engineering is a disciplined art, so let’s create some large scale masterpieces.
This article is a curation and rewrite of Stanford University co-alum Jessica Su’s Quora answers and discussions, later drafted after her due permission by Jayanth Kumar.
The Right Approach to Software Engineering was originally published in Technopreneurial Treatises on Medium, where people are continuing the conversation by highlighting and responding to this story.