Over the last week, I’ve been reading Judith Rich Harris’ The Nurture Assumption, where the author exposes the idea that children are not so much influenced by their parents as they are by their peers. Most examples Harris gives us during the book show that the environment in which children grow up is a lot more powerful in socializing them than their parents. Despite best intentions for getting children to behave in certain ways at home, the world outside and other children are the keys to derive their social behaviors which might or might not impact their adult lives.
This got me thinking about a very simple observation from the workplace. Put mediocre engineers in a team of great engineers and watch them grow. It seems obvious once it’s stated like this doesn’t it? And yet how many people forget about this simple principle when applying and choosing a job?
Let me elaborate a little bit on this last rhetorical question. Imagine you’re looking for a new job and after some arduous code tests and technical interviews you finally have a couple of offers in your hand. As a software engineer you want to work with a hopefully recent and great technology (whatever that means for your particular industry and interests), get a nice salary and work on challenging products. These are the most common requirements when thinking about a job offer.
- What technology do you guys use?
- How much am I going to get paid?
- What will I be working on?
These are the typical questions I hear from candidates in interviews. A surprisingly small number of candidates ask the question “What does your team look like and how do you work together?”.
The reason why that is surprising to me is that working in a team of great engineers who put the focus on sharing knowledge, helping others and educating the team has the same power as essentially compound interest for your career. In other words, it’s a snowball effect disguised in plain sight. Tools of Titans’ author Tim Ferriss already said that you are the average of the five people that you spend more time with. I’ll propose here that you should be using that when it’s time to choose a job.
Let’s think about this for a moment by examining each one of these questions in more detail.
If you take the job with the most recent technology does that guarantee you’ll grow your career, become smarter and get more money in the long run? Maybe. That’s an honest answer. Technologies come and go and in a software engineer’s lifetime you’ll probably end up working with dozens of programming languages, frameworks, and techniques. Do you want to bet your career in Angular’s success? What about Spring? Should you be the .NET MVC guy? I’ll grant you specializing in a particular technology that could allow you to surf a wave of clients and projects for as much as a decade with great return on investment, especially if you work as a consultant directly for clients, taking out agencies and other services middlemen. But surely you can’t be thinking in realistic terms to be using this 15 or 20 years from now and counting on it to pay your bills?
Speaking about bills, what about money? Surely you can’t be saying that I shouldn’t take the highest paying job, all other things being equal. Again, my answer will be maybe. It will depend a lot on which phase of your career you are, on your own personal goals and just responsibilities. Maybe you have a family that depends on you. Maybe you want to make a big investment in a couple of years and you need to save some cash for that. The point is, this will be a contentious answer no matter which way I put it. The reason why I’m bringing it up then is to give you an alternative view to the common position, which is just taking the highest-paid offer. What about taking the offer where you’ll be working on more difficult challenges? What about taking the offer where you’ll be working with a great team? If you apply some long term thinking to this, and taking some numbers to illustrate this example, you might be refusing company’s A 50k offer to go work with company B on a 40k offer that allows you to grow at 4x the pace you would in your highest offer. Presumably, you will be adding much more value in a year or two at company B that the managers will have no choice but to promote you. The worst-case scenario on company A is you being tied down to a 50k+ job in 2 years' time without any real options to grow from there. The worst-case scenario on company B has you not being promoted by the managers, still making less money than on company A but with confidence and skills to command higher offers from other companies, should you decide to leave. Of course, this is dependent on job markets, but just for the numbers themselves. Value is value, no matter what part of the globe you are and if you add value people will jump at giving you opportunities (and money to go with them).
The last of our three questions have to do with what will you be working on. This one is probably one of the most relevant for me. A good product can help you learn a lot about software architecture, design, and patterns. Working with legacy codebases, while not pleasant for the most part, could provide an opportunity for relentless refactoring, assuming quality checkpoints such as automated regression testing are in place. Again, the answer here about your career growth becoming tied directly to the projects you work on is maybe. The project can go horribly wrong and yet you learned so much from it that you have newfound confidence about tackling other challenges in the next project. The project can also be cruising along well and you can be working on maintenance with very little emphasis on actually improving the product. And this will have me jump straight into my last question and the one that I consider to be the most important one to ask.
Who do you think will have the better chance of becoming a great software professional, in the long run, the developer who ended up working with his favorite technology, in a challenging project by himself (and making more money in the meantime) or the developer who had to learn something new from a great team that put time in to teach him and offered so much advice on how to write code, design practices, and architecture that he now can teach it himself?
I truly believe it’s the second. Great teams make great software. And great teams are hard to come by, but that doesn’t mean they don’t exist and surely it doesn’t mean you can’t ask about them in a job interview. The environment around us plays a huge role in shaping everything about us. A smart coder turned loose in a team that plays along well with anybody will transform him, one can say 10x him, to use the famous 10x metaphor. Humans are a social species and as such, it’s only natural that we learn from others. I can definitely see great developers ending up in crappy (or non-existent) teams, working in recent technology stacks and what it just brings them unhappiness. Unhappy developers are not productive developers. And developers that are not productive don’t learn as much, which directly translates into career stagnation.
Conclusion
Stretching to learn by yourself is a great strategy for growth but it doesn’t beat working 8 hours per day in a team that throws so much feedback and knowledge at you that by the time you realize it you are the equivalent of a veteran in your lone wolf friend’s company. Bringing it back to the idea of compound interest, your learning, your drive to excel, that is the principle. We can assume it will grow linearly throughout time. What you learn via your team, that is the interest that you get and this will grow exponentially. The key to accelerating your career growth is then, counter-intuitively, to give it to others around you and not focus on it yourself too much. Think about it the next time you’re interviewing for a job and who knows, you might just 10x yourself in a couple of years.
Top comments (0)