There’s a big difference between writing code and being a great programmer.
While there are a plethora of ways to learn the basics of coding, developing the supporting skills can sometimes be much more difficult. There’s no simple online course that can teach you how to better collaborate with your team.
And there’s no single way to improve your own cognitive or problem-solving abilities.
So, how exactly do developers go from capable to good? From good to great?
Sure, there are some innate abilities that may give certain programmers an advantage over their peers. And others may struggle to grasp the basics. But, the barrier for most engineers looking to go from good to great is not genetics or luck.
It’s dedication–it’s passion.
In order to become a “rockstar” engineer (cringe), one must not only be smart and capable. You have to want it. You have to be willing to dedicate a whole heap of time and energy into becoming masterful.
You must be deliberate in your approach. No one becomes an accidental master of anything. It takes focused effort and a clear vision for what it is that you want to accomplish.
Then it takes a plan for how to achieve that mark.
Now, this isn’t to say that it’s all-or-nothing. But it’s important to understand the fundamental gap that exists between the majority and the truly extraordinary.
Beyond just dedication and passion to the craft, the engineering mindset is also a hallmark of those who are successful at problem solving of all types.
This is typically defined by its 8 main characteristics.
While some developers may be predisposed to have these characteristics, that doesn’t mean that the engineering mindset is entirely predetermined. It can be learned and consciously developed over time.
In order to develop your ability to evaluate and solve problems, you need a way to measure and assess that performance.
What makes someone a good developer in the first place?
There is no single, definitive way to measure performance (there are a lot of ways not to measure it, but that’s not helpful) and there is no static scale by which you can compare performance between two developers or teams.
In other words: The best way to assess a developer’s performance is to measure their growth over time.
If you want to become a better runner, what would you do?
You probably begin by setting a goal and developing a plan. But, how do you know if you’re making progress toward your goal?
You measure your abilities.
You time your runs, track your distance, and compare your speed. The same applies here.
Whether it’s the number of story points completed within an iteration or the quality of code written–it should be measured as a continuous trend over a defined period. If your score was 10, than your goal should be 11.
As with running, the process is this:
- Define a way to measure your performance
- Measure your performance
- Set a goal
- Continue to measure and compare performance over time
- Identify and test new strategies for improving performance
- Once you’ve reached your goal, repeat Are you becoming objectively better, quicker, or more efficient?
Understanding the fundamentals of any particular skill is the most essential step toward mastery.
Consider the game of chess. Before someone can become a Grandmaster, they must first understand the underlying principles of the game. Not only do they need to know how the bishop moves across the board, but also understand openings, positions, and tactics.
For developers, there are two categories of fundamentals that are critical to mastery:
- Engineering fundamentals
- Language/framework fundamentals
The first set is universal for nearly all types of programming. It’s about understanding the underlying structures, processes, and frameworks for effective programming.
In the second set, we look more to specialized fundamentals–specifics to certain languages or frameworks that are being used within a certain context. Programmers may not be experts at all languages or frameworks, but having a solid foundation can often make it easier to pick up new technologies.
For our purposes, we want to focus on the engineering fundamentals.
What does that include?
Although these look different in different languages/frameworks/paradigms, the fundamental logic is relatively static.
It may be tempting to think that if you are already capable of writing functional code that you must already know the fundamentals. But, do you really understand all of the underlying science?
Even competent engineers sometimes lack a true understanding of why and how things work in gory detail–they just know which keys to press in which order to make it happen. The interesting paradox is that these fundamentals actually become more important later in your career and as your work becomes more complex and further from the basics of writing and understanding code on a screen.
This means that many developers go years–even decades–without truly understanding the fundamentals.
But, eventually, they hit a wall.
As problems become more complex–as you attempt to grow and become a better engineer–you must master these fundamental concepts.
Otherwise, they will eventually become a barrier to your development. So you need to be deliberate about dedicating time to this basic part of the craft. As with anything, this means carving out time for deliberate and focused effort–training.
Fundamentals are – well – fundamental.
But, knowing the underlying components of programming != being a good engineer.
Programming is fundamentally a problem-solving exercise. It’s about taking in data, understanding context, and formulating the best possible solution. Probably the most important part of developing any problem-solving ability is repetition and pattern recognition.
It takes practice.
The more use cases you encounter, the more context you have for how to solve each subsequent problem. You’ve seen more problems and developed more solutions, which gives you a greater pool of knowledge to draw from in the future.
So how can developers apply this mechanic to improve their individual abilities?
It may seem improbable that you can somehow train your brain to be a better engineer. But there may be some scientifically backed ways to accomplish it.
One is to simply practice the kinds of thinking that are important to problem solving. And, maybe more importantly, practicing our ability to switch between these types of thinking in order to better and more easily discover solutions.
In general, we have two kinds of thinking that are deployed when solving problems or learning new things.
- Focused thinking
- Diffuse thinking
With focused thinking, we concentrate on a particular problem or question and actively try to come to a solution. With diffuse thinking, we let the idea incubate in sort of a latent or passive thinking mode–we’re not actively concentrating on it, but it remains somewhere in the back of our minds and we continue to look for solutions or patterns.
When it comes to improving your abilities as a developer, it turns out that both of these types of thinking are important. Some problems can be solved through sheer will and concentration; but others may just require more time and contemplation.
Not only are side projects often an indicator of passion and drive, but they have some broader benefits for you as a developer.
The major difference for side projects versus a day job is that you are exposed to more perspectives.
Rather than simply being a developer as part of a team, you become a project manager, a CTO, and perhaps a CEO as well.
Wearing these different hats–and without any external pressure–you’re able to better grasp the context of projects and products. You step outside of your role to understand the bigger picture and use that to make better decisions.
We learn and grow, in large part, by consuming the work of others.
While it can sometimes feel a bit abstract to consider your work outside of the context in which you created it, analyzing another person’s work gives you the chance to step outside of the code and try to deconstruct and understand the thinking in a new way.
Make a habit of partnering with different team members to review or analyze each others work.
You don’t need to make it a formal process, necessarily. But, simply taking the time to examine and consider the thought behind someone else’s code or structure can inspire new ideas or push you to improve your own abilities.
Learning is great. But retaining and applying knowledge is really what’s important.
It can often be difficult to take something you’ve learned and recall it later when it’s time to use that knowledge.
There are some tricks and strategies that will help you solidify the knowledge you have learned and identify opportunities to apply those learnings well into the future.
The idea behind interleaving is pretty simple. Studies have found that people are able to better learn and recall new concepts if they mix up what they’re learning–alternating between a few different concepts or practices.
While time blocking can be effective for developer productivity, the concept of interleaving may actually be better for learning and recall.
For many, the best way to learn is to teach.
If you understand a complex problem enough to explain it to someone else, then you’re much more likely to be able to apply that knowledge in a meaningful way.
Teaching is, of course, an exercise that encourages and requires knowledge to be actively recalled, explained, and applied.
So, teaching what you learn can be a fundamental strategy for retaining new knowledge and improve your ability to recall and apply that knowledge to your own work later on.
As developers improve their skills, it’s often helpful for them to solidify that knowledge by sharing with others. Either through formalized teaching or coaching, or though informal mentoring of other teammates.
At the end of the day, an individual’s abilities or knowledge will only play a small role in the outcome of the entire team.
Being the smartest person in the room won’t make you a great developer unless you use that knowledge the foster and improve those around you.
Teamwork and collaboration are just as important as the ability to write elegant code or solve difficult problems. In fact, it may actually be more important for have a functioning team than any one person be a particularly high-performing developer.
Application development is a team sport. Period. Full stop.
Sure, there may be mythical stories floating around about individual developers who performed some Herculean task of building programs all on their own. And that’s great for them.
But that’s not the real world–and it’s not a sustainable way to build software.
As you progress through our career, you will work with (and may embody) many different types of developers. And in order to do your job well, you will need to learn how to traverse different personalities and work most effectively with these different types of people.
More importantly, diversity can help you grow as a person and also make your team better at solving problems.
But, “being good at working as a team” is a bit too abstract. How do we actually assess and improve our skills and collaboration, discussion, and giving/receiving feedback?
Each person on your team should be aware of their abilities and have an understanding of how they are able to complement one another. If your weakness is algorithms, the best way for you to improve on that weakness is to understand who is better than you and actively work with them to develop your skills.
You can only do that if you’re open and honest, communicating clearly with the rest of the team.
You should consider how your strengths or weaknesses then define your role within the team structure.
Are you the one who is seen as reliable and efficient? Or are you the out-of-the-box thinker who pushes the team to explore new ideas? Whatever your ultimate role is, you need to consider how it plays a part in the overall team dynamic and how you can play that role in a way that helps drive better outcomes.
Beyond just being a proficient programmer, the most effective software developers have a broad understanding of the context within which they operate.
What does that mean?
It means that software is not created in a vacuum.
Strong developers understand that there are institutional considerations that go beyond just writing functional code and checking off user stories in the backlog.
Software is created to serve a purpose. And it operates under a particular set of conditions, within a specific budget range, and for users that have a certain level of knowledge or ability.
In other words, software is not just software. It is, ultimately, a solution for something.
But, to level up, you need to look beyond what’s on the screen.
In order to improve your abilities–and your value–as a developer, you should strive to zoom out from the day-to-day monotony of writing code and ask why.
Gain context and understanding about how decisions are being made and how they will impact your work. But, don’t just do it for selfish reasons–do it because you want to be included in that decision-making process and able to better understand the purpose and importance of what you do.
7pace Timetracker is the only integrated, professional time management solution for teams using Azure DevOps.
Posted on by: