Things I’ve learned as an engineer over my career (non technical edition)⌗

Put junior engineers in the deep end⌗

Engineers need room to breathe and think. Very few engineers are able to solve a problem competently under pressure of multiple people watching them and within a tight time frame. It is however prudent to give newer engineers bigger and bigger problems to solve to help build their knowledge, confidence and understanding of the system and problem space.

Junior engineers should be given problems to solve and left to solve it with ample support. This support should take the shape of unobtrusive yet supportive. By this I mean either leaving the engineer to solve problems with frequent check ins, or guided paired programming where the junior engineer is at the helm.

The key points to achieve are

1. Give them something achievable
2. Ensure any questions are met with understanding, and encouragement
3. Know when they have been pushed too far and sit with them to solve the problem
4. Feedback when they do something right (ask a good question, solve a problem, point something out etc)

Don’t give newer engineers ‘crap’ to write⌗

Its tempting to tell yourself you are helping junior engineers by giving them the dirty work, which often includes or is solely based on the unit tests.

Not only is this bad for the junior engineer, who is made to feel like they are being shoveled the grunt work, but even experienced engineers should be writing their own unit tests to help ensure they are writing usable and maintainable code.

Engineers sell this to themselves as helping to teach the juniors the code base, and while this can be true and beneficial, the harm comes from leaving engineers to only work on items like unit tests without experiencing writing real functional code - and without feeling like they are making a meaningful contribution to the application.

Be aware of whats going on around you, not just on your project⌗

Focusing too much on the assigned user stories can mean we lose sight of whats actually important. Lots of engineers fall down the trap of simply focusing on the work, and not on what actually needs to be solved.

A good example of this is constantly reacting and solving a problem, rather than working towards fixing the cause of the problem. This isn’t always the wrong choice, but it needs to be exactly that, a choice. If we just solve the problem and never understand the cause, more and more problems or technical debt will build up.

Without situational awareness of your current project, you can easily spend the time solving immediate issues and letting technical debt build - from daily tasks to frequent outages, it’s possible to end up buried under repetitive tasks.

Be open and communicate frequently and cleanly⌗

Too many times have I seen junior engineers left out of meetings, and not been given an update, only to find it was pertinent to them.

Worse yet, those junior engineers were sometimes a key engineer, whose consultation would have proven invaluable, but they weren’t considered due to their rank. Unfortunately this is all to common, and invariably the outcome from those discussions is not shared or documented. This leads to huge loses of time as engineers are unaware of a new direction or decision.

Inversely, I’ve encountered engineers who overshare, and almost drown their teams in information and thoughts, leading teams to spend inordinate amounts of time reading and digesting information before being able to suggest their own decisions.

Ideally, communication should be similar to git commits, little and often. By ensuring your team gets at least the decisions and key points from a discussion they weren’t part of as soon as possible, you avoid information overload while still ensuring everyone is kept up to date and included.

Send the time making sure they understand⌗

During my time as a junior engineer, I was struggling on a project and asked one of the seniors for help. They said a single word answer and waked off.

The support I would get were along the lines of “Just use X”, “Its simple look at Y”. It got much harder to ask more questions, and thus I was stuck a lot longer on the problem than if they had sat with me for a short time.

Make a point to not answer with a single response, but instead try and talk it through the problem and help the them understand areas they can improve.

Be aware of technical debt and its build up, and don’t use the simple management technique of faster = better⌗

Technical debt is a loan, and one that gains interest quickly, and unpredictably. The more unplanned work you have as a result of technical debt, the more unpredictable the sprints are.

We are constantly met with the struggle of velocity vs predictability vs reliability, and it incredibly difficult to figure out what should be looked into to ensure our deadlines are met for new features, while also maintaining the application. This can be made easier however by avoiding the quick answers, and always selecting the fastest solution instead of the correct solution. This seems rather obvious, yet I’ve seen this failure many times.

Learn from and be patient with those in areas trying to help you, they aren’t working against you⌗

This is one of the hardest areas I’ve seen development teams struggle with, and almost always it’s bred from an inability to communicate effectively from both sides. I’ve heard leaders say things such as “I don’t suffer fools” or asking the same question of multiple people until they got the answer they wanted to hear.

The issue here is its easy to find people a struggle to communicate and ignore them. Software development is often hard to communicate effectively with those that are less technical. To be effective, we need to put effort into understanding each other, and gain more skills in communicating effectively.

Most of the time, people aren’t trying to be difficult, they just are poorly communicating something they feel is important or are passionate about. They won’t always be right, but it is always right to listen to them.

It can be difficult to argue for the right thing⌗

There have been times where its been a lot of effort to do what I believe is the right thing, and try to convince others to come along with you. Although having to bring others with us is the right thing, it can become tiresome if you are trying to convince other members of the team constantly, and where there is lots of infighting.

Ideally, discussions need to be productive - and the only way I have found to do that is to ensure three things.

1. The discussion scope, what you want to achieve.
2. The discussion is to figure out the right answer, not convince anyone of your answer
3. Not everyone will have the answer in that hour, and its okay to come back to it later to let people digest the problem.

Any variation away from these decisions (unless its a bit of a crisis, then position three can be lost) will often mean the discussion is nothing more than a room of people talking.

Be wary of technical debt and its build up, and invest time into paying technical debt down before you can’t afford the interest⌗

Yes I know, a repeat, but for good reason. Technical debt is a huge issue, and as we discussed has been used to bury teams many times. Not only do you need to look out for unplanned work and the hazards it causes, and avoid always doing the “fast” work.

We also need to invest real time into technical debt, and not use magic time. Instead of the mythical “When you have downtime between sprints” we have dedicated time to paying down technical debt, which should be substantial enough to meaningful close of a chunk of work.