Why cool doesn't work

the difference between junior and senior developers


So imagine you have this new business idea and want to hire some top-tier developers to meet your demands. The interview process in itself is a very complex topic and people with far more experience in regards to recruiting struggle to recognize good developers.

Let's assume that you've got some developers out of college with a CS degree - they are not absolutely new to software development and programmed some GUIs in their lessons or even built frontend themes for Wordpress and earned some experience and money through that work. Maybe they've built a simple app, too.

So now you want to start your project and the first question for the developers might be:

  • How can we organize the code? (assuming they heard about git and version control before - if they hadn't, they are not a good fit to think about the software development process)
  • How can we manage the project? - agile, scrum with TDD, how long should a iteration last?
  • Which indicators should we use to measure efficiency and productivity? (again, if some of the developers want to use Lines of Code, it's not a good idea to let them create the process)
  • What are the deployment and backup and security concepts? (again, if they've never heard about threat models or redundancy, it is not a good fit)
  • What about tests and CI?
  • Which framework should we use? (This discussion will be very exhausting, because everyone has opinions about every frontend framework ever written and very strong arguments for their favourite framework, which are most of the time entirely subjective)
  • software architecture (very complex, should only be done by very experienced developers who've built complex systems in the past)

If you don't have the resources to hire a project manager, you need a tremendous effort and discipline from your developers. It is very easy to dismiss best practices to just get things done™, but this is a recipe for disaster. If you're investing in software development, make sure that your team is focused on building a solution that will last several years, not only months. If they tell you that no one ever wrote tests and that the best idea is to rewrite the whole project from scratch (which will fail, too, for the same reasons it failed the first time), calm down, drink a cup of tea and look for more experienced developers as lead developers and refine the process.

So why did this happen?
You've talked about tests and CI and version control from the very beginning, but all they tell you now is that they didn't listen to their own advice.

The problem is: They don't know it better. They understand it in on a purely intellectual level that all those ideas are great, but they've never experienced this engineering process and understood that every line of code is actually technical debt.

So this is where a senior developer comes into the game. He doesn't care about that new framework for this project - he used that framework in a side project or two and knows the ins and outs of it, but also recognizes the fact that there is a big difference between subjective preference and actual value delivered for the product owner. He prioritises "this works" above "everyone nowadays is using this thing, it is cool, therefor we should use it, too". This person should manage the impulsive youth and direct them to concentrate their efforts to build a solid product.

You also have to be very careful that your senior developer is conservative, but not outdated - if he wants to use Java for a web project and recommends <frameset> and rejects HTML5 for no valid reasons - he may be very experienced and worked for over 20 years in the industry, but his technical knowledge is worthless. It is true that cloud computing is just a fancy new word for a concept from the 50s called mainframes - but the senior developer should know AWS regardless; if not, he's not able to give you sound advice.

The distinction between a junior and a senior developer should be therefor only partly linked to the years they've worked. The definition of those words are in fact so broad, you could see them as buzzwords.

So I would like to correct the title - "cool doesn't work, but old without wisdom, neither."

What we've learned so far:

I tried to explain why software projects fail. Most of the time you don't have the resources to hire the best people who follow best practices and work responsibly which results in massive costs and risks, because you don't meet your deadlines or never receive a working product.

The truth is, I don't have a solution for this. There is no definitive answer and you will always be a victim of the principal-agent problem, unless you start to do code reviews - but if you start to do that, you can't focus on your business.

The reason I don't have solution is this: You have to trust people. You can't know everything, so your technical advisor processes the information for you and highlights the important facts. But if he fails to do that or you don't listen to the problems, you'll have a problem. This is not only a software development issue, but a big management problem associated with transparency for every topic which involves very domain-specific knowledge.

my 2 cents

So the only advice I could give to resolve this issue is: Select your recruiter very thoroughly, because he will decide who will join the company and build the product. If he isn't thorough and has specific knowledge about psychology and the CS-related topics, he will hire people who can advertise themselves and prefers a senior developer who didn't build wisdom and instead has a list of anecdotes which can impress the recruiter, but doesn't tell him anything about his abilites.

Finding this recruiter is possibly the most difficult thing, because he has to be able to recognize technological knowledge and personality types and - the hardest part - find out if the other side is telling him lies and actually doesn't have a clue. In my opinion it is not a good idea to use classical interview questions i.e. asking for algorithms, because you can hide the fact that you don't know how to build ready-to-sell software fairly easy behind theoretical knowledge and people who can build complex web apps may have never heard of big-O notation, so you would miss the opportunity for a great hire. Another possibility is that he seems shy and you think his insecurity stems from his lack of knowledge - although the Danning-Kruger effect tells us that actually the reverse could be true.

It is preferable if you can build a recruiting team with different people who can combine their expertise, although you should be careful that they don't judge outside of their domains - if the psychologist says that the interviewee seemed very knowledgable about that CS topic, it should not matter for the evaluation, because it is none of his business to judge CS-related things.

I can't tell you what is right or wrong, no one can and should do that. But I hope that some of this words can help to sensitize the management that titles don't matter as much and that trust is very relevant if you don't want and can do anything.