7 Tips On How To Become A Competent Software Engineer
This article is a collection of tips aimed at young engineers just starting in the industry .
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.
Ownership
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.
On the off chance that your administration goes down or a basic bug is discovered — stop whatever pleasant component or intriguing building crap you're right now on to, and settle it. This is hard working attitude 101. It is difficult and takes a specific level of development. You should get accustomed to it.
There will be things occurring as an afterthought that may influence your zone and you have to keep them on your watch.
For instance, your administration is sitting tight for a usefulness as of now being chipped away at by another person. Either pursue him/her (considerately) or do it without anyone else's help. Continuously endeavor to get this show on the road.
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”.
Final Tip
Do not. Delete. Production database.
