Multiple times many of you might have wondered what makes someone a good Software Engineer; in most of the cases there’s a tendency to think that having an intelligence way above the average is the only way to be a good Software Engineer.
I’ll tell you one thing: that’s totally wrong!
I’ve been in this sector for almost 15 years and I can strongly affirm that intelligence doesn’t guarantee being a good Software Engineer or Developer.
Intelligence gives you the ability to solve problems quicker than others, seeing things that others won’t see or maybe be able to foresee some problems earlier than others, but that won’t make you good at writing code.
Let’s say that all the benefits that someone could get by being intelligent could be largely overshadowed by all the disadvantages brought by not being a good developer: writing ugly and unmaintainable code, poor design choices, poorly tested code, etc
I’ve seen some incredibly intelligent people writing the most horrible code I had seen in ages and at the same time I’ve seen not so clever or experienced people writing such a clean code that it could impress anyone; so there must be something else that makes the difference.
If intelligence is not the key to be successful in this sector, what are the factors that could make of you a good Software Engineer? Well, it’s hard to come up with a magic, “it-works-every-time” solution, but I’ll give you some hints that I guarantee you it’ll get you closer to your objectives.
Let’s go through each of them!
1. Avoid Copy and Paste at any cost
When I was starting my career I used to do Copy and Paste a lot; when I say a lot I really mean A LOT! This definitely was one of the biggest mistakes I made when I started.
The problem with Copy and Paste is that you’re actually not learning much, you just grab some code here and duplicate it there and you miss all the important details within those chunks of code that you copy everywhere. One more thing to keep in mind is that it also leads to code duplication; but hopefully I don’t need to remind you that!
If you don’t start writing code yourself every time, then you will never get fluent with the languages, the libraries or the frameworks that you use in your day-to-day work as a developer.
For instance, if every time that you need a Builder pattern you Google it, then Copy and Paste the solution and just tweak it to your needs (something that I’ve seen very frequently), then you’re not learning anything at all; you won’t be able to write a Builder pattern from scratch by yourself!
Please stop doing this, you will never get better if you continue doing this!
Of course once you get very experienced, you could relax this rule and avoid unnecessary work when it doesn’t add any value; I hope you understand the point and that you’ll be able to apply it in a sensible manner.
2. Read at least 30 minutes every day
This is one of the most import pieces of advice you could ever take in this sector.
The IT sector is a fast-paced environment where things are in constant change and evolution, so you have to keep moving as well.
If you just stop for a few months and disconnect completely, if you move slower than the market, then I guarantee you that when you’re back into the market you will notice the difference and you will need to catch up!
The IT sector is a fast-paced environment where things are in constant change and evolution, so you have to keep moving as well
In the same way that going slower makes a difference, if you make an effort to go faster than the average, it will also make a difference!
This is where daily reading comes into play; if you make an effort to grab a book every day and dedicate at least 30 minutes of your time to read, learn new things and assimilate new concepts, you can be 100% sure that the effort will pay off in the future.
Dedicating just 30 minutes of your day to educate yourself, to improve your skills and abilities, will be more than enough to create a competitive advantage with respect to others in the market! It doesn’t sound like a lot of time, does it?
Just imagine that every time that you’re reading and learning something new, someone else is checking new posts on Instagram, watching Netflix, playing video games, etc. If you dedicate that extra time to reading, you will have a competitive advantage next time that you apply for the job of your dreams over those that spent their time on other stuff. Makes sense, right?
If you’re not sure about what kind of books you could read, I have a few recommendations for you; these are all books I read in the last decade and I found them very useful:
- Clean Code: A Handbook of Agile Software Craftmanship by Robert C. Martin
- Effective Java: 3rd Edition by Joshua Bloch
- Working Effectively With Legacy Code by Michael Feathers
You might be saying “I don’t have time for that!” or maybe “I’m too tired in the evening for that!”; stop making up excuses, there’s always time, I’ve been there before as well.
You have to get to know yourself, if you concentrate better in the morning or maybe in the evening; if you’re able to focus and read productively in the tube, etc.
Get to know yourself!
Once you get to know yourself, pick the best time in the day that works for you. For me the time it works best is early in the morning, so I normally wake up early (around 6AM) and I read while I have my first coffee in the morning or right before I start working; that works for me, but that’s completely personal and different in everyone of us.
3. Use TDD as a design tool
Many people see TDD only as a way to force you writing tests first, but they miss the key point of TDD: TDD is a very powerful design tool.
The main reason why TDD is a good design tool is because, when followed strictly, it makes you adopt some good practices that will make your design simple, testable and maintainable.
Not only that, remember we were talking about clever people coming up with a solution faster than others? Well, with TDD that doesn’t really matter in many cases.
TDD will lead you to the simplest solution without having to make a big intellectual effort to come up with the solution, so I’d say that TDD helps closing the gap between those who are more intelligent and the average.
If you’re unfamiliar with how to follow TDD, you could take a look at my article “TDD explained: Practical example” to know more about it.
4. Do Pair Programming with more experienced developers
Pair Programming is a very good exercise for knowledge sharing; however, I don’t think that it should be enforced in a team. Pair Programming should be encouraged but not enforced, it should happen in a spontaneous manner among those members of the team with the right mindset.
Not all the stories are suitable for Pair Programming either, the team should decide when to work on pairs in some stories when they consider it’d be very beneficial. The benefit could be for a Junior Developer absorbing coding skills knowledge from a more Senior Developer or maybe just sharing business domain knowledge among different team members.
Sometimes it also helps two members of the team to know each other much better and it helps to build up a sense of a team.
The bad news is that some people are too individualist or they just avoid human interactions in general, so they don’t like Pair Programming at all. Don’t try to enforce Pair Programming on those individuals and focus on those that could enjoy it and bring results to the team; why those reluctant members are part of a team is a question that each team should answer themselves.
One more thing that could also be beneficial for some teams is to organise mob programming sessions every certain period of time; in these sessions the whole team works together on the implementation of a feature or on writing a solution for a coding kata. This is very helpful to see other points of view and every now and then someone in your team might surprise you with something new!
5. Open your Mind
I’m well aware that we all have our own egos; no one likes being told wrong, but you have to do everything you can to change this.
Being open-minded and open to new ideas and even to criticism in some cases, will allow you to make improvements and take new skills onboard more easily.
It’s also beneficial to take a more active approach, always try to look at things that could prove you wrong and not the other way around.
Most of the times we’re looking for a reinforcement of our ideas and opinions, because that makes us feel good; what we should do instead is to look at any evidence that could lead us to being proved wrong. For example, Google for exactly the opposite of what you think, until you find no clear evidence of being wrong or until you do!
Actively look for any evidence that could prove you wrong
This is a very healthy and smooth way of exercising an open-mindedness in ourselves; if you practice it consistently and in an active manner, you’ll notice how slowly you stop feeling uncomfortable with those that disagree with you!
6. Watch tech talks
Watching tech talks is a good way of knowing different perspectives and new trends in our sector; some of them will be useful for you and others won’t, but it’s always good to know different perspectives.
There are plenty of good conferences nowadays that you could attend to, but if you don’t have the time or the money, many of them can be found on Youtube freely.
Another thing that I find useful is to look at some resources that could point you out to some of the new technologies that are worth reading about or even trying. I sometimes use this Technology Radar link by ThoughtWorks to take a look at what kind of things have become trendy recently and see which of them may be useful.
There are also many e-learning platforms nowadays that have a whole bunch of awesome videos about different topics that you could be interested in. These videos are normally prepared by professionals with an extended experience in the topic, so most of the times you will learn very useful things with them.
7. Practice, practice & practice
Lastly but not least, we do have to practice our coding. Practice at work but also practice at home when you have time, this is very important!
Doing coding katas is a very good way to practice your coding skills and your TDD skills. There are plenty of resources with examples of coding katas, you’ll be able to find them on Google very easily but if it helps, one of the links I normally refer to is this one.
Another great way to practice is to set your own side project, yourself or with some colleagues or friends. This will allow you to look at different things to what you normally work on at the office.
The main objective is that you become fluent with the language and gain speed and agility when writing code; and the only way to do this is by practicing frequently.
“Everybody’s gotta learn, nobody’s born knowing.”
Harper Lee
If you are interested in learning more and get a better software developer, we highly recommend to read the following Software Engineering books:
Conclusion
The path to become a good Software Developer might be different to every one of us, but I think the key is always consistency. Set your own goals and stop comparing yourself to others, the only thing you should care about is if you’re better today than what you were yesterday.
Take that mindset and apply it to every single day in your life; in the long-term you will notice the improvements.
Follow these good habits for a long period of time and it’s almost guaranteed that you will become a much better Developer than what you are right now.
Steady progress and consistency is the key here, don’t try to study long hours the first weeks and then quit; start slowly but steadily, the chances of being able to keep up with that pace in the long-term are much higher than if you try to take on too much at the beginning.
So that’s it from me! I hope you’ve enjoyed this article and that you may take some of this advice into practice. Looking forward to seeing you again soon!
Thanks you very much for reading!
One comment
You must log in to post a comment.