To read more articles like this, visit my blog
Running a startup is exciting. You are part of a journey where the destination moves constantly.
Hiring and managing people is even more challenging. A well-organized team is the most critical asset for a startup.
In my experience as a founding member of a startup — and after working for multiple startups in the last 3-4 years — I have noticed that the outcome of a team depends more on chemistry than technical strength.
Today, I will share my experience with older programmers and why startups should avoid hiring them.
They Have More To Lose
Younger programmers are eager to take risks. They have nothing to lose. They can bet on a promising technology or change to a different tech stack.
But the case is different for older programmers. They have spent their career working on a specific technology. Maybe they are very good at it, but technology’s not guaranteed to solve every problem.
They oppose adopting new technology in these scenarios because they suddenly go from experts to newbies!
In one job, I had difficulty convincing my boss that React was a good choice instead of JSP for a frontend application because he was a Java developer and wasn’t willing to learn React!
They Are Too Technical
Technically perfect is not bad — especially when you have much time. But getting things done out of the gate is the #1 priority for most startups.
As a startup, you have to try out many things. You don’t even know if the feature you build will be in the final product.
But older programmers often care so much about the technical nitty-gritty that it becomes impossible to get things done.
The scenario is different when a team is working on an established product. Achieving high quality is mandatory there.
They Are Sometimes Political
It’s obvious. When someone is starting as a junior or even mid-level developer, their primary focus often is to improve their skills. They know there is room to grow and are eager to do so.
They enjoy their time learning new tech and talking with like-minded people.
But as devs grow older, they get involved with many things. It becomes harder to distinguish them from business people. I don’t think that’s necessarily a bad thing. It’s even required in some cases.
But in startups, most of the time, integrity and friendliness are the main traits in demand. A business-type mentality can create conflict among other developers.
They Are Often Outdated
We all have our choice of technology. We try out many things but stick to particular ones all the time. Programmers are biased people.
For example, I love working with React. I am aware of the fact that it will not remain as popular as now in 20 years.
But will my older self be able to switch to another new language easily? Will I have that energy, courage, and time?
Probably not.
That’s precisely why older bosses often try to impose their technology of choice on junior devs. That’s why they have to do some pretty weird stuff.
I had to serve a React application bundled inside a Spring Boot application because our backend apps were written in Java.
The logic was, “That’s how we do it here. Can you argue with that?”
Final Thoughts
I am aware of the value that experienced programmers bring to the table. And for the system- and architecture-level design, you should have someone doing this for a long time.
They can also do a decent job of managing people, but it can backfire when it comes to technical jobs.
For enterprises, the case is certainly different. Older programmers should be there because they have more experience handling challenging situations. But for startups, it is not the same.
Get in touch with me via LinkedIn or Personal website
Top comments (5)
I think it depends on what you consider a senior developer. I don't think developer seniority necessarily equates with age.
Seniors should be able to switch stacks pretty easily, since they're just learning a new syntax to solve problems they already solved many times before. Some seniors are stuck in their ways, but you can say the same thing about junior developers that learn one framework and decide to use it for everything.
For MVP's and startup projects, you should always go with the technology you and the team are comfortable with. If you are learning how to build and grow a business, you don't need to learn a bunch of new tools as well. The end product should be stable and as bug free as possible, but it should be something you and the team are comfortable with debugging, even if it's not trendy.
If the MVP succeeds, then you can grow, switch stacks, etc.
But juniors are more likely to introduce technical dept that is hard to be paid off.
It's good to know what my younger coworkers assume about me (:.
I think flexibility is more tied to personality/risk aversion than seniority.
I personally see early startups going for senior and staff engineers and then adding a few entry level when they are trying to save money. You need someone who can think through and plan out large features, with low technical debt, rapidly. Usually experience helps with that, although sometimes extreme intelligence/speed can help also.
Your perspective sheds light on some of the challenges and dynamics that can arise when building a startup team.
Wow , Interesting point of view