I've worked with dozens of highly skilled developers during the course of my career. And the more you work with somebody, the more you pick up on the way that they do things. Especially the things that they do right.
Because there are commonalities in the way that senior developers / lead developers / architects, both, think and work and I'd like to think that after 20 years, I've picked up on a few of these.
I'll start this off by stating that none of these items I'm about to list involve the number of languages, number of frameworks, specific frameworks or anything having to do with what a developer is doing. It's more so about how they go about doing these things.
3. They don't turn down project requests
The only way to learn anything, is to get involved and to do it yourself with your own hands. But when you're working for a large organization, you typically don't call the shots in terms of what you are going to work on. At least not if you're just getting started.
It takes time before tech leads and project managers build up enough trust to assign a complicated task to any junior developer. Or even a senior developer for that matter, if they are new at a company. I myself spent the first 6 months of my career shadowing other developers and making very small adjustments to windows forms. It gave me a chance to get familiar with the companies workflow and I didn't speak out too much during that time, at least in terms of wanting to work on something new. Because frankly, I was terrified to.
After some time though, my name began to circulate as to 'who would be able to work on... (fill in the gap here)'. But typically, the request would come in like this:
Can you work on this new project? We need it by this date and time? You think it's possible?
It was never really an order, by any means. At least it didn't seem that way. I felt as if I could have easily said 'no thanks' and someone else would have been CC'd in the email.
My answer was a very hesitant "Sure, I think I can do that?". And the reason why I was hesitant was because I had never worked on anything remotely close to what I was being asked to do here. And to this day, that has become the most difficult task that I have ever worked on.
I took alot of risk here with this project, mainly because the deadline was super short, the specifications were complex and my skills were subpar. But I can almost confirm, that this project was what readily solidified me as a full-stack web developer back in 2008. It involved database schema creation, wireframing, server side logic, client-side logic and even design, as there was none given to me.
Even after almost 20 years as a programmer, I still feel the nervous pangs as I get asked to work on something that's completely new to me. But I still say yes, and it typically only takes a few days of work before the nervous energy dissipates and the results start to show.
I'll state now that this is valuable at any stage of your career. I've met senior developers with 20+ years of experience who still only worked on a single language, a single framework and who refuse to work on anything that's new and different. And in the end this just makes you much less flexible and limits the amount of work that you can realistically do.
2. They refactor their code frequently
You're only as good as the code that you are writing today. Meaning that if you have code sitting around from last year, then it's probably time to revisit it once more because there's a high chance that there is something wrong with it.
Or perhaps, you might even have a better way of doing something and an update is in order. Typically for me, refactoring helps me to remember the business logic on more complicated systems. And if anything, gives me an opportunity to rethink certain choices that I made in the past.
When I worked with more senior developers (as a junior), they would often pick a day in the week that they would dedicate entirely to refactoring. The company was aware of that and they didn't interfere with the process. And because of that, development on that codebase was relatively easy.
A big goal of refactoring is to reduce redundant and duplicate code as much as possible. And that can take time to master, because you have to be keenly aware of every function and how and where they will be used in the future.
And, you're also more likely to break things during your refactoring process. Meaning that your QA skills need to be sharp as well. I made the mistake early on in my career of refactoring large chunks of a codebase, only to come out days later with new and cryptic errors that would take a substantial amount of time to debug and to fix.
My current refactoring workflow is much different than it was back in the day. For one, I'm much more selective as to what I'm going to be updating for that day. I have test cases prepared ahead of time and I'm constantly unit testing every change that I make.
But this is a part of the process. You will inevitably break things, as you try to improve them. But the more you do this, the better your process and the fewer errors that will inevitably form. And in the end, you'll end up with a much cleaner codebase.
1. They write generic code
The best developers out there, don't usually think in static terms. Atomic values today, will inevitably lead to some limitation tomorrow. What do I mean by generic over static, you may wonder.
Say for example that you are tasked with creating a from that captures 3 values from a user. No more, no less. The quickest approach is to just create 3 input controls, capture 3 different states, and store these 3 items somewhere. Pretty straightforward and everyone goes home happy at the end of the day.
It may not follow database normalization rules, but it gets the job done.
Until they get asked to store 4 values instead of 3. And then 5 instead of 4. In which case, copy and pasting will only take you so far and you will inevitably end up with redundant code.
Good developers think about generalizing values from the very beginning. And that means making more lookup tables in a database, and creating generically named functions that take more parameters.
function storeItems(items){
// generic code that stores each item 1 by 1
for (let i = 0; i < items.length; i++){
storeItem(items[i]);
}
}
function storeItem(item){
}
Even if the function only gets used a single time in the entire codebase, having it be flexible from the very beginning can make future updates much easier.
If you are working with languages, such as C#, then you will be familiar with the concept of generics. Generics essentially allow you to design classes and methods that defer data types until after these class objects have been declared. Not only does this allow for generalizing code, but it still maintains type safety and efficiency within your classes.
All in all to say that writing reusable code is a complex process and it takes time and experience before you get good at it.
Few last words...
Nobody starts out knowing all of these concepts or being good at them. And that's because they require a substantial amount of time to solidify as experience.
I do all of these things now, but I definitely steered away from all of this during the first few years of my career, because in general they were complicated, took more time and typically they involved me having to rewrite my code.
But once you get through those growing pains, you'll find the value in frequent code refactoring, generalizing and in consistently working on things that you have never worked on before.
Walter Guevara is a software engineer, startup founder and currently teaches programming for a coding bootcamp. He is currently building things that don't yet exist.