Or things I realized a bit late
It’s hard not to sound preachy when writing something like this, however I will try my best (this issomewhat of a preaching, so can’t promise anything). The following are some of the opinions on technical and non-technical aspects of software engineering I have developed over a few years in the industry. Some of them are strong, some not so much. They will probably change in the next decade or so, however I will try to be as true to the real life experiences as possible.
Sturgeon is right 90% of the time
90% of everything is crud
That’s what a sci-fi author had to say about science fiction material. This has proliferated the general nerdsphere as somewhat of a universal truth, with a little change to the original quote, “90% of everything is crap”.
As I’ve experienced, this is especially true for most of the tasks done during a typical day of a software engineer. The code, the designs, and even the engineering done will mostly be made obsolete soon, or they would end up being too rigid and brittle to last a considerable time through evolution of requirements. This is sometimes covered in the concept of over-engineering, although it’s hard to be self-aware about this all the time.
The point is that most code you write will go unexecuted or deleted out of the repository sooner than you think. Most use cases you design for will never actually happen in the real world. Most “bugs” you solve before they actually occur will never be bugs to the end users.
Take coding. Most literature analyzing software design and implementation show that only a handful but real user experience based use cases will result in the most useful parts of an application. However, to get the real user feedback there should be something in the real world, running, humming along, interacting with real users.
It was easy for me to be ideological about “clean code” or “design patterns”. However it took sometime for me to understand that I used the adherence to those ideas as a virtue than the essence of the ideas themselves (so before you accuse me of being dismissive of those ideas, I do not dismiss them, I just don’t subscribe to them as eternal truths). This will easily become a matter of ego than functional outcomes of your day to day work. As in, you’ll start considering your code as something to look after emotionally rather than realistically considering them as something to break down and improve. You’ll try to hide your code until it is “perfect”, wasting precious time that the same code could spend getting feedback from actual users.
(This doesn’t mean you should produce sub-par code and be happy about it. Of course, you should develop your skills to a level that writing functional code is second nature. There is almost always no perfect code. Just different ways of doing the same thing. The quicker you surrender to this truth, the happier you’ll be)
There are different styles of doing things, writing code, designing systems. Develop your own functional, consistent one and stick with it. Focus more on getting a usable product out and improve it iteratively.
Avoid premature optimization like the plague. You will save a lot of time.
Competent team members are better than one silver bullet
Arguing to arrive at a decision is overrated
Do not waste time — overcome procrastination
One of the hardest habits I struggled with early in my career was procrastination at work. Transitioning directly from a university student role to a junior software engineer was in some way a shock to the daily (and the nightly) routine I kept up to that point. That was certainly not the first job I had to hold, however it was the first in my career. Adjusting to a routine where keeping focused and somewhat uniformly paced day time and a relaxing night time was something that took a long time for me.
I overcame procrastination after sometime (a bit too late in my self-criticizing opinion), however over the years I have started to see the same patterns of behavior in some junior engineers, especially those who directly transition to an engineering role from the academic role they held up to then.
There are several proven ways of getting out of the procrastinating habitual loops. Anything that works for you as an individual should be good. For me, it turned out to be something simple, but clever. More on that later.
The goal should be to spend your energy reserved for focusing on the work that should be get done in order to succeed as a productive engineer.
Try your hardest and best to develop a routine that minimizes procrastination.
Master the trade
Coming from an IT background (as opposed to from a CS background) and being an okay student, I was a bad engineer when I started being one. There is no way around that fact. So there was an obvious list of competencies I was lacking as a junior engineer.
However, that’s what is being a junior engineer is. You get a chance to learn, make a few mistakes, and develop experience while taking risks with somewhat of a protection from your senior developer(s). However, it helps to master the tools of the trade as soon as possible.
These could be the broader topics like knowledge on various build tools, version controlling systems, developer eco-systems, IDEs, dependency management tools, OS tools, deployment tools, networking and infrastructure gotchas, and being able to explore different programming paradigms to solve problems. Or they could be minute details like how to design a packaging hierarchy for a certain programming language, how to run a benchmarking tool for your code, or even what your opinion is on what a good logging format should look like.
These are certainly details you develop over the course of a few years. However it would help if you actively work on developing them. The best approach to develop your own experience is to dabble in pet projects. With the unlimited ways of doing the same things, chances are you have a gap in your developer experience at your work. You can try to design and write some tool that would solve that gap. You can try your hand at a different programming language than what you use at work while you do this. That will force you to think in a different set of structures to solve problems, and will make things interesting.
Master the tools of your trade
Go home
To do any of this, you need to have some free time. Unfortunately this is what most software engineers seem to lack. Some down time for yourself.
When I started my first job as a software engineer, I would look for any chance to keep working on a certain problem until the day turned into night and to the next day. I had so much energy to “engineer stuff”. However, especially in hindsight, I see that trying to expand your work hours beyond the normal time is an absolute counter-productive way of doing things(unless you are in a crunch cycle).
If you come to work on a certain day, determined not to leave until your work is done, you are most likely to procrastinate during the day. This is because you have no temporal challenge (you have unlimited time) or the incentive (you can’t leave until you “finish” the task, so you don’t have an immediate goal to look forward to) to finish the task. You go out for tea/smoke/coffee breaks often, because you “need that fuel in the tank”. You spend more time at lunch because you’ll be staying late anyway. And at the end of the day when you start the actual work, you were no where near completing that task than you were in the morning.
At least, this was the case for me.
Instead of that target and plan your day at work to be within the normal work hours. Try to start work in the morning and leave at a fixed time (after putting in the amount of hours you’re obligated to of course). As explained above, this will be better in so many ways.
- You have an immediate deadline to work towards, when you start work in the morning. 8/9 hours from now on, you should complete what you’re doing to a reasonable stop point and leave. This will give you enough of a challenge to focus on the important work (more on what’s important later)
- You will be forced to break larger tasks into smaller ones to successfully divide them between work days. This is a good practice to develop from early on. You can’t leave in the middle of a coding frenzy where ideas keep generating at your fingertips. So you’re forced to estimate and plan
- You will have precious free time to cool yourself. It is pretty easy to burn out mentally being a software engineer, if you don’t have a backdrop (life outside work) contrasting enough to make the work itself interesting.
- You will have free time to work on your own pet projects. As explained above, this will be when you’re polishing your skills, the proverbial late night carvings in the candle light. Unless you turn off from your work effectively you will not be able to do this
To come back to a point I made earlier, how I managed to overcome my procrastination to a certain level was to limit my work day to a fixed number of hours. With a little bit of planning I could also shift my hours to a range outside the rush hours of traffic. With the level of traffic jam nightmares during the rush hours in Sri Lanka, this was a huge stress reliever.
I had to let go of the odd range of work day later, however my habit helped to always keep to the work hours (as much as the work culture allowed at the time). I was able to write, code, read, exercise, and most importantly relax better during the free time I got out of that.
Go home
More on this, in this precious little video -> https://www.youtube.com/watch?v=YBoS-svKdgs&t=1s
One more note on this topic. When it comes to work-life balance, Sri Lankan IT industry is notorious for not having one. Then again, software engineering itself is not a job like some other 9–5 jobs where you can just turn off and go home at 4.45pm. This is especially because being a software engineer needs a certain level of care and attention to grow yourself as a successful engineer. And there are frequent occasions where you have to dedicate time outside of normal work hours to get something done, a release, a production deployment, or a critical bug bash. These are the hazards of the trade (other than the diabetes and the fatty liver you’d get unless you’re careful).
However, there will be people in your line of work that will tell you that there is no such thing as work-life balance. That it’s a choice between being a good software engineer or having a life, and you can’t have both. After all, with a little thinking you will also be convinced of this “fact”.
As soon as you hear this line being uttered (because chances are you will), make a promise to yourself to get away from those people and places as soon possible. That “logic” is the basis of the exploitation of your eagerness and passion towards the craft to drain as much work out of you as possible. Chances are that these people would be ones that you consider as mentors or even role models. If that is the case, you need better role models.
I know successful engineers who are the best family men/women, best hikers around, who are talented self-taught musicians, history buffs, and some who have developed businesses (in areas other than engineering) out of their homes. Anyone who tells you that there is no balance between work and life is probably a failure at finding the balance themselves.
Do your work properly and go home. Spend time with your family. Draw a painting. Write a blog post. Stare at the wall. Find life.
People not liking you is alright
Take care of health
Written on by .
Originally published on Medium