7 software engineering tips after 7 years of experience

I’ve been doing software engineering for 7 years already, and I gathered a set of tricks that help me at everyday work. These tricks are completely technology agnostic, they don’t refer to any specific programming language, project management methodology, or tools used. Be aware that they work for me, it doesn’t mean they are going to work for you. I noticed that many of them have something to do with writing and collecting information (this makes sense, considering that Input is one of my top strengths in CliftonStrengths). So, here are seven software engineering tips after seven years of experience:

1. Write down your steps when you work on something difficult or long-running.

I wrote an article about my personal worklog, where I share how it evolved over time. At the moment it’s built from multiple Google Docs files, where I list things that I did in chronological order.

I have multiple files, depending on the context. One for projects at work, one for this blog, but also one for taking care of my plants or my medical history. 

Each of them has a similar structure: there is a timestamp, and then a description of things that I did. It can contain screenshots, links, code snippets, or pictures, but should never contain secrets, passwords, etc.

I found multiple benefits of creating such a log file.

It helps me remember things that I did, in case I have to revert the changes. Sometimes something doesn’t work, and I don’t know why. I try different solutions, and when I finally find the working one, it would be nice to clean up all the wrong solutions. 

It helps me remember things that I did, in case I come across the same issue again. It could also happen that, even though we fixed the problem once, it will happen again in the future. Or even in a different project. We can remember that we experienced this before, but we could have forgotten the exact steps and the solution.

It is useful for UI changes that are not possible or easy to automate with code. If something involves setting something up in the UI it makes sense to describe the flow and keep screenshots in case we have to do it again in the future. 

It could be the first draft of the documentation. If we are not sure if what we are doing is the ultimate solution, but we still would like to remember the steps or the commands we used, it could serve as a reference point. 

2. Plan your steps in writing before you start executing

There is this saying “fail as cheaply as possible”. It applies to multiple fields and it works in multiple contexts. Google calls it “shifting left” as I wrote in the article about better decision-making. I apply it in my daily work, by preparing a list of steps in advance before I start the actual deep work. 

I can observe multiple benefits of planning in writing before executing:

• We can see how big the problem is. During the initial estimation, we might have overlooked multiple aspects. The whole project’s estimation may be lower than the sum of its parts. 
• Alternatively, we can explicitly reduce the scope because we know what the project involves.
• We can identify dependencies before we start work, so other teams can already be prepared, and we can prepare a list of questions to ask in bulk, instead of interrupting others every few hours. 
• We can identify problems and blockers when the initial idea becomes infeasible. Changing the plan at this stage is cheaper and easier than if we already had a working code covered with automated tests.  
• We can come up with a better technical design because we understand the bigger picture of the solution, instead of taking only the first part or idea.
• We have a list of all things to do which can help us move forward if we feel blocked. I wrote more about this benefit in this article.

This rule also helps me write better documentation. Instead of starting right away, I first try to prepare an outline. It’s easier to rearrange the text structure at this stage, than later when we have a full text already. It also allows me to make the documents more focused and concise because the outline is more thought-through. 

3. Don’t be afraid to ask for help

Our work is hard and frustrating. It involves making multiple decisions, dealing with unexpected issues, and myriads of moving parts out of which everyone can break at any moment. On top of that, there is remote work and a lack of interactions. Sooner or later we may feel bad, and antisocial, and withdraw even further into a miserable cycle. 

One thing I realized was that we can actually talk to others about it. It was hard at the beginning, but I did a thought experiment, and you can do the same. If someone asked you for help would you refuse? I wouldn’t. That gave me the courage to openly talk to my manager, and also to ask work colleagues if they have ever experienced the same.

4. Start an activity that involves selling and marketing something (including yourself)

At the beginning of my career, I was very frustrated because of the constantly changing requirements and the need to push things forward so fast, without ensuring enough code quality. 

And then I started my first business, furniture e-commerce (Zabawa w dom). It changed my point of view. The code quality of my online store didn’t matter to me that much. Why should I spend hours making my website scalable, and flexible, if people didn’t even buy my products? Time was limited and I had to decide what to focus on. And it usually involved things like marketing and SEO. 

Before I started this blog, I had tried to run a blog two times already. Initially, I was mainly focused on the technology behind it. I used Gatsby, I created everything myself, and I spent hours organizing code architecture and preparing a components library. And when it was finally “ready”, I didn’t have content to publish. 

This time was different. I installed WordPress, and I bought the template. I focused on content and promoting it. Instead of building components in TypeScript, I learned about keyword research and how I can be better at writing. 

The benefits that I gained from this adventure were:

• I developed an empathy for marketing and sales teams. It’s still frustrating when I have to do unexpected and urgent changes, but now I know where it comes from.
• I learned the basics of hard skills such as SEO, marketing, sales techniques, tracking, and data privacy.
• I stand out (at least that’s what I hope) from the crowd of people with similar expertise.
• I improved my writing and language skills a lot.
• I learned how to accept good-enough solutions. 
• I understood the importance of getting feedback as quickly as possible.

5. Disable notifications (unless you are an on-call engineer)

It’s impossible to achieve a state of focus and deep work if we are constantly distracted by a notification popup. What I learned over time is that it doesn’t matter that much if I answer the question in 3 seconds or 13 minutes. If I would respond to every message immediately I wouldn’t be able to work and move important projects forward. An additional benefit of that is a feeling of satisfaction and accomplishment if we complete a task instead of interrupting it multiple times.  

It may require a discussion within a team, to manage expectations regarding response time, as I wrote in the other article about using Slack effectively in a remote team. 

One exception is being on-call. In these cases, it probably makes sense to enable notifications, because every minute may be crucial. 

6. Embrace the fact that software engineering is not only about writing code

I remember from my early days of being a software engineer that I was very frustrated that I had to “waste” time doing all the unnecessary work. It took me a few years (and a book) to understand that my job is to solve problems, not to write code. 

Writing code is a way to achieve business goals. But it’s not limited to that. Actually, we can think about the code as a liability, not an asset. The more code we write, the more systems we have to maintain, and more bugs to fix. 

Additional activities that we also need to do as software engineers:

• understand the problem scope – that involves multiple meetings, sometimes with non-technical people who don’t speak our language.
• design a solution – which involves a lot of writing, drawing, talking to people, and asking for opinions.
• influence others – whenever there are more people, and decisions need to be made, we have to influence others. It could be choosing a particular framework, or design approach (e.g. monolith vs microservices). 
• test it – sometimes with automated tests, sometimes manually.
• deliver it to infrastructure – building pipelines, selecting the infrastructure, and comparing costs.
• monitor the solution – performance, logging, and reliability.
• verify if it brings business value – for example with feature flags and A/B tests.
• document the solution – so that other people (including future us) can understand how it works.
• interviewing other people – because if the business is successful, the team grows.
• removing old code – when it’s not used anymore but increases the complexity of the system. 
• learn to give and receive feedback – because we often work in a team.

7. Keep a list of your work achievements

Inspired by this article I created a document where I collect a list of things I worked on every week. 

These are the benefits of doing this:

• When I have to fill out the list, I think about what I have done, and that helps me celebrate the progress, and see new things that I have learned. That in turn contributes to overcoming the impostor syndrome. 
• It helps me prepare for my salary negotiation. I have a clear list of achievements that I can quickly remember and use.
• The same applies when you’re switching jobs. If you have a question about your achievements, you are already prepared. 

Summary

It’s clear that these are not all the work habits that help me achieve professional goals. And it’s clear that they don’t work for you, as they do for me. But if at least one of them feels inspiring to you, I’m happy.