10 lessons from three years as a developer

I’ve been a professional software developer in the banking industry for three years. Here is a knowledge dump of some important lessons and observations I’d like to share. If you’re just getting started in your software journey, or if you’re a seasoned pro, I hope there’s some golden nuggets in here for you!

It’s OK not to know things

“The more I learn, the more I realise how much I don’t know.”

Albert Einstein

Let’s face it, when you’re new, there’s going to be a lot to learn. And guess what, even when you’re experienced, there’s still a lot to learn, except now you’re even more aware of how much more there is to learn.

But that’s OK! This is literally what the job is - to analyse problems, explore solutions, and to learn what is required to implement those solutions. As a developer, you will never know everything by heart. You will learn things, forget things, and learn them again. And each time you do it, you will get better and better at it.

There is no such thing as a stupid question. If you’re ever in a discussion or meeting, and there is something you don’t understand, politely ask. Chances are that that if you don’t know what’s being spoken about, others wont either. When it is explained, it will become clearer to everyone, not just you. Be brave and ask! Check out Simon Sinek’s advice in this short video: The truth about being the “stupidest” in the room

How to handle feedback

Feedback is a vital part of your progress. If you’re new, sometimes, depending on your team and onboarding process, it may sting a little. You spend hours on a story, getting it absolutely perfect. You are so proud of submitting your first pull request for your new team. But now it’s up for code review and getting some feedback!

It’s important to not take any comments or criticism personally! It’s simply feedback from the developers who have been maintaining the codebase for perhaps serveral years or more. They will likely have standards, practices, and tools in place that are there to make life easier for all contributors, including you!

Aim to seek as much feedback as you can, from both technical and non-technical people in your team and organisation. This is how you grow.

How to give feedback

Much harder than taking feedback, is learning how to give effective feedback. It depends on your role as to the type of feedback you will be giving, but most likely it will be in the form of code review, but sometimes you will provide technical feedback on something from non-technical team members such as UX designers, content designers, or business analysts/project managers.

This is such an important skill to master, although in my opinion, it really just boils down to being respectful. Sometimes although you have the best of intentions, people can take your feedback the wrong way (especially in written format where you can’t convey tone).

What I like to do is give feedback in person or on a video call where possible. This brings in the human aspect, and shows that you are engaged in their work. This is often a much nicer experience than receiving a wall of text, or a sequence of comments on a pull request or in a chat. This also provides an opportunity to do some pair-programming to solve the issues, or walk someone non-technical through a problem and show potential solutions.

When to speak up, and when to listen

When you talk, you are only repeating what you know. But if you listen, you may learn something new.

Dalai Lama

When you‘re new, your goal is to absorb everything and learn as much from the more experienced developers on the team as you can.

But you’ve also got value to give! You most likely have experience from a previous job, or as a student, and life experience in general (which is more valuable than you might think!).

Don’t be afraid to challenge ideas, or provide your own, in a constructive way. Often things are the way they are for a reason, and so by challenging an idea, you’ll learn why it’s needed, and why another approach may not quite be viable. But what you’ll also find when doing this, is that makes the rest of the team question the status quo as well, which spawns new ideas.

As you become more experienced and familiar with the codebase and tooling, you’ll be called upon to speak up more in meetings, and contribute to making decisions. This happens gradually, and sometimes it can be hard to know when to speak up, and when to shut up and listen.

Start with the problem, not the solution

When presented with a problem, first seek to fully understand it. Put yourself in the shoes of the customer or user, and seek to understand the pain-points.

I’ve found that when people come to you with a problem, those problems are often disguised as solutions - but solutions that do not necessarily fit the problem. They get tunnel vision trying to force their solution to work. In these situations, take a step back and consider the big picture. Is the solution the right fit for the job? Nine times out of ten there is a super simple alternative available, that just makes sense. Often the simplest solutions, are the best solutions.

It is also the case that people will create solutions and then look for problems for it to fill, rather than the other way around. Always start with the problem!

The power of iteration

Done is better than perfect.

Sheryl Sandburg

Perfection does not exist. If you wait until a project is perfect until you release it, it will never be released.

Your aim should be to maximise that value that your project brings. As soon as it provides any value at all to your organisation, even if it is not finished - release it.

By releasing it, you’re not only providing value to the organisation, but you’re also getting feedback from your users. You can use this feedback to prioritise features and fix any issues raised.

Then with each iteration you publish, the application becomes more and more useful, refined, and valuable.

Pick a niche area to specialise in

A quick way to gain respect among your peers is to pick something within your area of expertise to really focus on, and specialise in. Become known as the “go-to-guy” for something - something that maybe is not so well understood at your organisation, but could greatly benefit from having an expert in it.

For example, as a front-end developer I chose to really dive into accessibility. This is something I feel strongly about, and it is becoming more and more important. It’s also something that is often neglected, and I feel there is a lack of education around it for a lot of developers and designers. I saw this as a gap that I could fill, and decided to become the local expert on the topic.

I consumed myself in all information I could find about the topic and applied it as often as I could to our stories. Before long, even as the junior developer, everyone came to me for advice!

By choosing a niche area and spotting a knowledge-gap to fill, you will gain confidence, enhance your reputation, and become an invaluable member of your team and organisation.

The difference between a good coder and a good developer

A good coder is just that, a good coder. But a good developer is not only technically-able, they are a well-rounded professional. They are excellent problem solvers, communicators, collaborators, team players, learners, and teachers. Here are some examples of the difference between the two.

A good coder, when given a task, may go away into isolation, complete the task alone, and come back later with a solution.

A good developer, when given a task, will seek to fully understand the task at hand. They will ask questions about it. They will plan out their solution and get feedback on it, perhaps even before writing a single line of code. As they work, they seek feedback from peers and stakeholders as they iterate.

A good coder may submit large pull-requests of changes, which takes a lot of time and cognitive effort for their peers to review.

A good developer makes small, succinct, easy to review pull-requests that build on top of each other, making their changes much easier to understand and review.

A good coder may have great technical skills, but may not be able to explain their work well.

A good developer is able to effectively communicate their work at different levels, so everyone from engineers to business analysts to designers to end users are in the loop.

A good coder may use their tooling of choice for a particular problem, because they are familiar with those tools.

A good developer makes sure to use the right tools for the job, even if it means learning something new. Great developers never stop learning, exploring, and teaching.

Work to learn, don’t work for money

When you are young, work to learn, not to earn.

Robert Kiyosaki

Early in your career, you should be chasing opportunites that maximise your potential for learning and growth. Seek out companies that have the best possible environment for you to grow in. Seek out companies who hire the best talent for you to learn from. Seek out companies that have a track record of taking on fresh talent, interns, graduates, and developing them into professionals. These may not necessarily be the highest paying roles on offer, but it will pay off big-time in the long run with the skills and experience you acquire, along with the network you will build.

The knowledge and experience you gain early in your career will become leverage for you to go for top roles later on. Don’t be tempted for a high paying offer from a lower-quality company that might limit your growth and opportunites.

Take a walk

Sometimes things can get a little difficult. It could be a coding problem, a requirements problem, or even a people problem. This is completely normal and is part of the job, and part of life. It can be tempting to stay late or overwork yourself when trying to overcome a problem.

However, most problems are actually smaller than they may seem. They can often be broken down into smaller chunks. You may need to look at it from another angle, or get a co-workers opinion.

“I can’t see a way through”, said the boy.

“Can you see your next step?”

“Yes”

“Then just take that”, said the horse.

The Boy, the Mole, the Fox and the Horse

This advice may seem cheesy, but it’s so effective. Take half an hour and go for a walk and get some sunshine. Let go of the problem - free your mind from it. When you come back with a clear head, often the path forward is right in front of you!

Show up

“Eighty percent of success is showing up“

Woody Allen

This one may be a little controversial. But here is an opportunity for you to set yourself apart from the rest. In the age of post-pandemic hybrid working, make an effort to show up to the office often. Okay I know what you’re thinking! But hear me out.

In the age where everyone wants to stay home, this is your opportunity to become the human point-of-contact for your team. This is your opportunity to make yourself available to help others, to be shoulder-tapped, to build connections. This is your opportunity to become a familiar, trusted face at your organisation.

Will you take that opportunity?