What I have learned after working for four years professionally as a software engineer.
It’s been a little over four years since I landed my first job and started to work professionally as a software developer.
Two years before that, I was a starry-eyed undergraduate that had just started learning how to code and was desperately hoping to become better at it. It was what I wanted above everything else at the time.
Here’s a quick list of lessons I’ve learned so far:
You have to actually write code
The thing that makes a programmer is writing code. You can do a bunch of other cool things as a programmer. But, you have to write a lot of code to actually become better at programming. It is the one thing you can’t compromise on if this is something that interests you. I clearly remember my first boss telling me this when I started out. Well, it is true.
Time, (and active coding, of course) will hone your skills
You need time to become good. Don’t get frustrated with yourself for not becoming better as fast as you’d like; but, do not relent on learning. You must actively learn.
Become an expert but be interested, and curious about related areas
It is very handy to have holistic knowledge about different parts of programming that relate to your specialization because knowing this will help you be better. You don’t want to be isolated in one area if it is really connected to other parts.
That said, it is more beneficial to focus on becoming an expert at something where software is concerned. You can always pick up something new to become an expert at, if you roll like that, but seeking knowledge depth & expertise is usually a good path to tow.
Burnout is NOT sexy
It is very tempting to ignore your health of mind, and body, especially if you get obsessive about work, or coding in general. Well, burnout can tamper with your love for programming, not to mention the fact that it has very disastrous effects on your body. If you can, avoid it with everything in you.
Coding interviews are broken, yes, but with practice, you will get better at them. So practice every chance you get — whilst they remain broken. Every interview is a step closer to getting better at the process, so, embrace it.
Accurately estimating the time and effort required for software building is difficult.
Production Code vs Tutorials
The code you practice with and or learn from and the code you will get to work with every day will probably be worlds apart in terms of complexity, patterns, et cetera.
Not planning your software and its architecture right will come back to bite you. The only question is how expensive the bite will be and if the initial speed you gained because you didn’t take the time to plan it is worth it. Hint, it usually isn’t.
That said, over-engineering software at the planning stage is unnecessary. If you need anything, it is often best to add it when you need it.
A team of good software developers that work well together, is everything!
A great project manager is necessary for software building to go well.
Paranoia is great for software engineering. Test everything.
Use a checklist if you want to do manual testing.
The effort, time and complexity involved in maintaining software, is always grossly underestimated.
Ease of readability of code is extremely important. Saves time and is way less stressful for the psyche. It is also more important than we are willing to admit. We spend so much time reading code when building on top of existing software that sometimes, more than half of the requirement of our tasks will be code reading.
There are different kinds of programmers and that is okay. People interested in programming for its sake and those who mostly care about what they create with programming. I believe that I am a mixture of both because I mostly got interested in programming after discovering what I could achieve with it. But I stuck with it because I enjoy it for its own sake.
The sooner you begin to take care of technical debt, the better.
Enforcing best practices and processes in software development is a good idea.
That said, it is always a better idea to make these practices work for your use case, in the best way possible. Basically, consider your situation and apply practices after evaluating them with respect to your own case and finding out that it makes more sense than not.
Software/Product documentation is extremely important. And for the period when humans still have to read and write code, we need to do this as best as we can.
I don’t know what the best programming languages are, but there are tools that work better for specific use cases.
Mastering one programming language makes it exponentially easier to pick up others — in a lot of cases.
You will write shitty code at some(every) point -whatever your definition of shitty code is. But, your code will get better. You must actively put in the effort to make it better though. And you won’t stop seeing ways to improve the code you wrote in the past. This is okay and completely normal.
Be very open to code critics, especially when you establish that the sole aim is to make the code better — by any standard.
To build a truly great software product, you need empathy.
Your Product, or what you create is more important than what you built it with. At every turn. So long as you use capable tools.
Don’t be careless with backups. Have backups and make sure they are up to date.
Learn all you can about software architecture. Evaluate critically to find one that works best for your use case. Be flexible about correcting this if you find out that what you have doesn’t work well.
Be proactive about being knowledgeable about security. It is very easy to relegate it to the background depending on your role, and daily tasks. You must fight this.
P.S: I am still learning a lot more lessons every day! And I will probably modify this if I realize there is something I missed.