7 Tips On How To Become A Competent Software Engineer
Throughout my 5+ years, I’ve had my fair share fulfilling different roles in the tech startup. Add to that a brief stint in academia.
If there’s one thing I learned being in a variety of roles, is that it gave me perspective. You came to realize the importance of things you thought didn’t matter.
Thus, this article is a collection of tips aimed at young engineers just starting in the industry based on my personal experience.
First Impression Matters
Always start out on a good note on a new job. Don’t be late, don’t be a dick, and don’t immediately start going on about why we need to move away from framework X.
Resist the temptation of trying to prove yourself on every chance you got. There are better, humbler ways of doing it. Read on.
Know How To Make Good Estimates
Identifying bodies of work and making estimates easily amounts to half of the communication between the tech and the businesses.
An estimate boils down to two things: when do you think it will be done, and how confident are you on hitting that date.
It is a skill you need to hone from experience, but I’ve got two tips:
- The bigger the chunk of work, the harder it is to estimate. I would always split a big task into smaller pieces, each of the size of 1–3 days worth of work.
- If you said it will take a week, they will ask, “OK, can you to do it in 3 days?”. Always be prepared to justify your estimate.
Own the service. Own the domain. Understand the business reason behind the service.
Identify problems and initiate improvements. Little by little. Don’t try to save the day.
It may take a while for you to feel that you actually own it. I guess it’s a bit like adopting a stray dog, you kind of feel for him a little at the beginning but you’ll grow more attached as time goes.
If your service goes down or a critical bug is discovered — stop whatever nice feature or interesting engineering shit you’re currently on to, and fix it. This is work ethic 101. It is not easy and takes a certain level of maturity. You will need to get used to it.
There will be things happening on the side that might affect your area and you need to keep them on your watch.
For example, your service is waiting for a functionality currently being worked on by another guy. Either chase him/her (politely) or do it yourself. Always try to get the ball rolling.
Strike A Good Balance Between Interesting Work And Important Work
Interesting works are those that are intellectually challenging. Think algorithm optimization, data structure work or artificial intelligence. It will definitely improve technical proficiency. It may or may not improve your service.
Important works are those that allow the company to pay our paycheck. Think of system integration with business partners or tweaking marketing templates so they look good across devices.
Sometimes, the most important work is not the most interesting.
We are engineers and we live to take on hard problems. However, we do have to balance between doing what’s fun and what’s important.
Strike A Good Balance Between Going In-Depth and Going Wide
Young engineers will want to have a 360° view of software engineering.
Don’t fall into the trap of thinking that you’re a front-end guy. Or back-end. Or DevOps. Learn all these areas, at least to some extent.
Don’t get me wrong. You will want to specialize. However, my point is to make sure you have some knowledge of the other aspects to some extent. Because in the long run, it will help you become a better engineer.
Remember, there is no such thing as a front-end engineer or backend engineer. There is only an engineer. An engineer’s job is to solve problems, so do it.
What Your Employer Wants From You
Details will vary from job to job and companies, but some things stay true no matter where you are:
- Nobody likes a moaner. Don’t moan because they get you to “update the wording of 15 different templates”, or any other kind of menial work. Moan a lot and you’ll see your peers climb up the career ladder faster than you’ll ever be. You don’t want to take on these jobs every single time, but there are better ways to get the good work besides moaning.
- Deliver. “It is finished, just waiting to be merged to master” means it is not finished. Merged to master plus deployed to staging / production is. Your employer will appreciate it if when you said it’s “done”, it actually is.
- Know key figures related to your domain. It will give a strong impression that you know your shit. Yes, it applies to software engineering. It goes without saying that fudging is the worst thing you can do. If you don’t know just say so, followed by “Give me 10 minutes to look it up”.
…And What They Would Rather Not
- When a critical issue arises, don’t hide ‘em. Tell your boss straight up that something isn’t working properly and you’re on it. Tell the business you can’t take on any other work before this issue is resolved.
- Don’t over-promise on delivery. The business gave you work you think can be done in 3 days. Promise them 6, not 2. Because hey, other things will come up and it’ll take you 5 days anyway. But you promised them 6, which means you will still “exceed expectation” and therefore is “excellent at estimating”.
Do not. Delete. Production database.