Photo by ThisisEngineering on Unsplash
Multiple times many of you might have wondered what makes someone a good software engineer. In most 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’ve ever seen, and at the same time, I’ve seen not so clever or experienced people writing such clean code that it could impress anyone. So there must be something else that makes the difference.
If intelligence is not the key to being successful in this sector, what are the factors that could make you a good software engineer? Well, it’s hard to come up with a magic “works-every-time” solution, but I’ll give you some hints that I guarantee will get you closer to your objectives.
Let’s go through each of them.
1. Avoid Copy and Pasting 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 was definitely 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 of that.
Photo by freestocks on Unsplash
If you don’t start writing code yourself every time, then you will never get fluent with the languages, libraries, or 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 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 important 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 stop for just a few months and disconnect completely, or if you move slower than the market, I guarantee you will notice the difference and will need to catch up when you’re back in the market.
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?
Photo by Olia Gozha on Unsplash
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 “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 6 a.m. 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 every one of us.
3. Use TDD as a Design Tool
Many people see TDD only as a way to force you to write tests first, but they miss the key point of TDD: it is a very powerful design tool.
The main reason why TDD is a good design tool is that, 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 to close the gap between those who are more intelligent and the average.
If you’re interested in having a better understanding of TDD, I’d recommend that you read “Test Driven Development: By Example” by Kent Beck, you can buy it on Amazon here.
4. Do Pair Programming With More Experienced Developers
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.
Photo by Alvaro Reyes on Unsplash
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 organize 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!
#programming #coding #software-engineering #software-development #startup