Jan 3, 2024 4 min read software

Learnings during 5 Years as a Software Engineer

Some things I learned along the way so far.

General Knowledge

You don't code for yourself, you code for future developers that don't live inside your head. Write Clean Code.
Automate manual tasks when possible. Every time you spend doing a manual task you introduce possible human errors in something humans aren't very reliable to do (repetitive tasks with a lot of precision aren't the best thing for a tired human at the end of the day).
When joining a new project, open your ears, and see what are the pains of the client, and the pains that the software will solve. That is how you start knowing the priorities of this project.
Communicate clearly to your leaders how much you can pull off, and if your estimates are wrong (don't worry, they always are) communicate as soon as you know the fact.

On dealing with difficult People

We should always keep in mind work doesn't happen in a vacuum. People's livelihoods are constantly in danger if they get fired for bad performance. And management's poor performance, when accurately tracked, is far more problematic to a company than other teammates'.

On Managers

With that said, being a bad boss and manager is not excused just because you're under pressure. I said all this because some people believe bad bosses are just bad people, which is not always the case.

People respond to pressure differently, some thrive under it, and some break. Everyone responds to degrees of pressure differently as well. A well-performing senior engineer might find lots of problems performing as a manager.

With all that into account, how do you deal with someone under a lot of pressure, either external or internal pressure?

The best thing is to keep things clear and to the point, to not sugarcoat things, and to say exactly what are the problems you're facing. The worst you can do in a failing project is hide the reasons for it to be failing.

There's a caveat to that. If you're in a very corrupt environment that will punish you for pointing out problems, then your priority should be to move to a better environment, especially if you're not in a leadership position. It's very hard to change corrupt environments from the bottom up.

But if you're a manager, you have better odds to change that, it will still be hard, and we can't expect the people on the front lines to want to stick with a company with a bad culture awaiting while you change the organization.

On Difficult Teammates

If you're in a team with people who withhold information that you need to perform at your best, or uncooperative teammates who prefer to throw blame rather than fix problems, HR has failed. They gathered people who don't work well with others, it's hardly the single engineer's fault for that.

What you can do is keep doing your best, and communicate what you can and can't do. And prefer to speak in common Slack channels vs DMs. That way any doubts, blockers, and problems you face will be public for all to see. That helps you to argue a position of pure blame in the future if it comes to that.

This is where I believe that a single engineer can make a positive change, as you show more communication and honesty, it's harder for people to throw blame. Especially if you share your challenges along the way. And it makes management know what to expect from you as well.

Honest communication is insurance. And also the most efficient path to solve problems. So win-win.

On Learning on The Job

You can always learn better by doing it on the job
[...]
I would focus on the foundations
I would focus with a science bent
I would develop a love for reading
That is a foundation for your self-education
[...]
The best way to learn game theory is to play lots of games
- Doing On The Job (ft. Naval Ravikant)

You think you got a job and now things are good? You can cruise now? Now it is when the real learning begins.

I've learned far more during work than outside. Every edge case I've met in React, Kotlin, Flutter, Python, and Java I've found during my work hours. Because it's when you're actually trying to do something difficult that has value to others that you start developing a different relationship with coding. A relationship of "How can I make this code do this?" instead of "How can I learn this language".

It's by providing value that code has value itself. Ergo: Nobody will pay you to make todo apps and CLI calculators.

Some people start to have the right relationship from the get-go because they start to learn coding by trying to do something, instead of just trying to "learn JavaScript/C++/Rust/Python".

What do you want the code to accomplish? Making clones of apps won't teach you more than trying to cook up an app you'd use yourself.

Once you have an intent, and it's easier when you're inside a company, then you learn as you solve problems. But you can also sneak up on awesome conversations by listening to dev podcasts, watching YouTube videos, and reading Medium/Daily.dev/Hashnode articles.

On Building Trust to Get the Job

You can build trust as an applicant for a job by solving really good problems publically. Either building amazing things and posting about them on social media or by being a great contributor to an open-source project.

Extra points if you work on an open-source project that the company you are applying for the job uses. Ex: the company uses tokio, and you want to be a rust engineer there? Start by contributing to tokio for a couple of months and then apply, I'll assure you you will have better odds, and devs in the company might even vouch for you.

By the way, I just posted a video on my main channel on "How I would learn coding if I had to start all over", do check it out and give me feedback on it. There is no improvement without feedback. Plus I tried being funny there, so if something is off, please let me know haha.