Career Development in Software

For the TL;DR version, I put my outline at the bottom!

I am the CTO of a small daily deals business in the small country of Lebanon. I have an eleven year career working in software development over a span of 8 companies, 3 of which I co-founded.

The goal of this article is to define the very visible differences between the four phases of growth of a software developer over his career. Many articles allude to these distinctions and I have found that opinions about the definitions are very varied without being too specific about the details. I will try to be as concrete as possible.

All of this is my opinion and my experience is solely in the startup world and not the corporate. Whenever I use male pronouns, I just mean person because I am male. What I write here is true for males and females.

Skill trees

In order of importance and required level of experience:

Technical

1- Software design and process
2- Language competency
3- Constantly updating knowledge
4- Problem-solving focus
5- Quality assurance practices and security
6- Bird's-eye view for architecture
7- Speed of context switching

Leadership

8- Coaching and ability to follow
9- Listening and interviewing skills
10- Initiative and tempered courage
11- Charisma
12- Maturity and the ability to admit mistakes
13- Consistent stability = Dependability
14- Command of one's self and others
15- Improvement of guidelines and best practices

Business

16- Negotiation and budgeting
17- Technical business knowledge such as accounting, cashflow, legal, and management
18- Clear goals
19- Proven track record and ability to show value. This is not about leadership, it is about proven experience and the ability to showcase its value ... like what I'm doing now

20- Presentation
21- Contacts
22- Politics and influence

One thing I do not mention here is the ability to estimate tasks, gauge risks, and meet deadlines. This is untestable as it depends on multiple undefinable factors such as the developer's familiarity with the language, familiarity with the code itself, understanding of the task, initegration with the code of other developers, and emotional influence from life outside of work to name a few. None of these can be clearly defined for various reasons. I prefer developers that give rough estimates while they constantly monitor their ability to meet deadlines to refine their future estimates based on their knowledge of the task at hand. Over-estimation is the better strategy when one wants to be safe.

What is expected of a junior developer

The most important characteristic that I look for in a junior developer is a drive to learn. I mean learn anything ... plain old curiosity. Not to the point of crushing anxiety or ADHD but just shy of that. Being inquisitive is the one trait that all good developers have in common and I often find that they all have some kind of unique quirk or esoteric knowledge that has nothing to do with their profession and is rarely useful in real life. Examples of this are: Ability to listen and be completely focused on two conversations happening at the same time; Being very calm and mature at a very young age, wise beyond his years; Being able to decipher unordered Japanese numbers by making correct guesses about the patterns in between them and the number of sides they have; The ability to solve a Rubik's cube in 3 minutes. Very isolated quirks that are unlikely to have been adapted from a book or other people and definitely require a lot of intense practice.

Passion for the work is imperative as well or he won't be able to cope with the long hours and changing demands. I personally do my best work after 13 hours of non-stop effort. I rarely do that now because I have learnt better ways of getting things done, but I wouldn't be where I am if I couldn't sustain that much focus over a long period of time.

Technical knowledge and skill in the expected programming language is important to get a head start in the learning process but good programming habits are more important. Examples of good habits are: Knowing that it is best to search for an existing solution to a problem rather than making one himself, understanding the importance of commenting hard pieces of code, knowing when to use one data structure over another, and knowing when to ask for help and when to try to solve something on his own. It's hard to teach these!

Lastly, a junior developer must be a team player. He needs to fit into the team he is thrown into and start adding value in a matter of weeks if not days. Frankly, a junior developer is usually an investment rather than a direct resource. Unlike an accomplished developer, a junior does not provide much value for at least 3 months and will not be dependable for up to a year. So the hiring manager must feel confident in the junior developer's ability to drive his own learning path, otherwise, it's usually not worth the effort.

What is expected of a senior developer

In addition to all the skills of a junior developer, a senior is expected to be dependable and socially capable. He needs to be demonstrably consistent in his performance and his ability to deliver bug-free code while enduring an intermittent stream of questions from other developers. He is also expected to participate in the interview process while continuously improving guidelines and best practices for the organization as a whole.

When a deadline approaches, it is the senior developer who works throughout the night without being asked to do so. He is expected to work well under scrutiny and strict deadlines while still mentoring other developers. This logically follows because he already knows the answers to many questions about the programming language and the software. Other developers will depend on him to provide quick answers while his manager depends on him to finish his technical work on time as well.

He gives constructive feedback to other developers without being patronizing. He tests potential candidates to decide which ones are capable of becoming productive members of the team. He defines the guidelines and best practices for the project which helps the development team, as a whole, become more capable of delivering on its goals.

I remember after 5 months of work, I had to work for eight hours to meet a second-day deadline only to accidentally delete the files I was committing to our versioning system right before committing them, I spent the next three hours cursing and rewriting all my code while the rest of my team worked around me late into the night. We all met the deadline but after that, I made it a guideline to make daily commits to versioning branches so that this does not happen again.

Lastly, he must feel confident enough in his technical skills that his answers are short and precise while his estimates are usually on target.

What is expected of a software architect

In addition to all the skills of a senior developer, the main separating factor of a software architect is a proven track record of successfully built projects. An architect is tempered by experience, having been exposed to different mentors, architectures, software needs, and operating environments. To name a few of my own: Websites with owners who expect super fast results without understanding the complexity of their requests; Banking accounting software that has to be accurate and well-tested even when the testing environment is behind so much security that running a single test takes seven minutes every time ... I basically had to run the entire software in my head from start to finish before testing it once; Platform-as-a-service database that can be used for small projects and enterprise software easily; E-commerce website under high security threat with a skeleton crew of developers; Marketing software with six different servers, three databases, four developers, three direct stakeholders, and a very short timeline for delivery.

All of these projects had to be designed and managed very differently because their limiting factors were very different. A good software architect cannot handle all of them using the same strategy because even if it does work, it will be sub-optimal. He cannot design the normal website architecture the same way that he designs the high-security risk project because it would never be finished on time. He also cannot treat the marketing software the same way that he treats the banking software because it requires a lot of multi-tasking instead of singular focus on points of security failure.

Secondly, he needs to be able to focus on a small problem while maintaining a bird's-eye view of the different moving parts of the software. The ability to switch contexts quickly is what is important here. He needs to be able to imagine all the moving parts running at the same time in order to correctly design the software with redundancies, fault tolerances, and as few as possible single points of failure. Much of this is in knowing when to switch his problem solving mode from depth-first to breadth-first and being able to prioritize the various problems he has to resolve.

Socially strategic thinking is part of this role too as he has to gain buy-in for his ideas from other developers. A company is not a despotism and developers tend to think for themselves often, so an architect who just makes plans and orders without taking into account the opinions of the highly skilled people enacting his vision will not be very effective. Aside from the fact that developers will always have a unique and useful perspective on their work that should not be ignored.

The best way to gain the approval of others is to simplify it so that people don't need to put in much effort to incorporate it into their own plans. An architect must be ready to answer simple and complex questions about his designs in an accessible way while also modifying his answer based on the technical perspective of the listener. He should never explain a solution to a manager the same way that he explains it to a developer as it would be far too technical.

Lastly, he needs to be up to date with technology. This is the fastest changing field in the world, so being ahead of the curve in terms of new technologies and methods will avoid unnecessary risk and solve problems before they occur.

What is expected of a CTO

In addition to having all the skills of a software architect, the main goal of a CTO is to transform business goals into software goals easily. The "easily" part is important here because if it takes him a long time to set the software goals it will impact the company's performance in the short and long terms. As with any C-level position, efficiency is key. That is why CTOs usually behave and look different from other developers as the requirements of the role are quite different. The demands of this role are strictly about the alignment of the technology progress with the business progress. There are no requirements of hours spent at the office, or number of bugs generated, or adherance to the latest technology updates. The performance of the technology department as a whole and its positive impact on the business as compared to its competitors is what determines the effectiveness of the CTO.

An important survival trait for a CTO is the ability to understand the position of different business parties in the company and its ventures. Be it investors, owners, customers, managers, employees, board members, or suppliers. Balancing the motivations of each must influence his decisions. Every day he brings some of these stakeholders into the fold while alienating others in order to meet the company's quarterly goals. Examples of this are: If he chooses to focus on one WiFi router supplier that is affiliated with one of the investors and not the other; If he chooses to promote one employee over another; If he chooses to disregard the recommendations of a manager. A department sometimes feels like a house of cards when you're at the top.

Lastly, getting his foot through the door becomes a little harder. Employers will no longer want to monitor his progress weekly or even monthly, they expect him to succeed. So they cannot gamble on this position and will inquire with his previous employers very thoroughly. Was he effective, was he well-liked, was he responsive to criticism. Suddenly, everything that he has ever said and every person he has ever talked to can come under scrutiny. Add to that the assessment of how influential his contacts are in order to aid in the company's growth. Even getting the job requires him to be in very good standing in the community and a few powerful friends doesn't hurt. This is a far cry from what a developer has to go through.

In conclusion

This video explains my thoughts on what it is to be a senior developer. I presented it at a workshop a few years ago when I was a senior. Watch
My views have changed since then. I used to think that senior developers were just junior developers with added leadership soft skills. This is only partly true because a very important difference between a senior and a junior is dependability. The ability to consistently perform requires more than discipline, listening skills, and control. It requires a much more solid understanding of the complex processes within the software life cycle. The most important influencers of a task are: Language, existing code, fitness of the other developers that will be integrating with the task, planning and pre-existing requirements, and parachuted tasks mid-development. A senior developer has to perform well at all times regardless of curve balls, within reason of course. So he cannot take too long to think about whether or not to add the DB code for a small fix in the controller or the model, the decision must be made quickly using his experience and it must be correct more often than not.

I think I'm going to miss the instant gratification of development when I actually assume a C-level position in a bigger company. Some of the most important things that I do now, take months to show results, but their results are far more impactful than most solitary pieces of code that I can bang out in an afternoon. Like ordering the development of automated sales reports that directly impact our marketing strategy.

The roles of a software developer throughout his career change greatly from one phase to the next and keep in mind that this is just one example of the basic roles. Some CTO jobs are required to be more hands-on with development like in startups, while others require more out-reach and influence like the CTO of an incubator. Just like some senior developer jobs require much more coaching and code review than actual development. Ultimately, the more one understands the processes around one's self, the better one will be able to manipulate them to one's own advantage. This list represents my own experience over the past eleven years. Your mileage may vary.

TL;DR

Outline:

1. Introduction

• I am the CTO of a small daily deals business in the small country of Lebanon
• I have an eleven year career working in software development over a span of 8 companies, 3 of which I co-founded
• The goal of this article
  • To define the very visible differences between the four phases of growth of a software developer in their career
  • All of this is my opinion and my experience is solely in the startup world and not the corporate
  • Whenever I use male pronouns, I just mean person because I am male. What I write here is true for males and females
• Separation of
  • Technical skills
    1- Software design and process
    2- Language competency
    3- Constantly updating knowledge
    4- Problem-solving focus
    5- Quality assurance practices and security
    6- Bird's-eye view for architecture
    7- Speed of context switching
  • Leadership skills
    8- Coaching and ability to follow
    9- Listening
    10- Initiative and tempered courage
    11- Charisma
    12- Maturity and the ability to admit mistakes
    13- Consistent stability = Dependability
    14- Command of one's self and others
  • Business skills
    15- Negotiation and budgeting
    16- Technical business knowledge such as accounting, cashflow, legal, and management
    17- Clear goals
    18- Proven track record and ability to show value. This is not about leadership, it is about proven experience and the ability to showcase its value ... like what I'm doing now
    19- Presentation
    20- Contacts
    21- Politics and influence
  • One thing I do not mention here is the ability to estimate tasks, gauge risks, and meet deadlines. This is untestable as it depends on multiple undefinable factors such as the developer's familiarity with the language, familiarity with the code itself, understanding of the task, initegration with the code of other developers, and emotional influence from life outside of work to name a few. None of these can be clearly defined for various reasons. I prefer developers that give rough estimates while they constantly monitor their ability to meet deadlines to refine their future estimates based on their knowledge of the task at hand. Over-estimation is the better strategy when one wants to be safe.

2- What is expected of a junior developer

• Drive to learn
• Passion for the work
• Familiarity with the programming language
• Good team fit. Not a good culture fit because cultures change faster than teams when it comes to startups
• Focus

3- What is expected of a senior developer

• In addition to all the skills of a junior developer
• Consistency in performance
• Works well under pressure, which is not a requirement for junior developers!
• Confident in his ability to perform

4- What is expected of a software architect

• In addition to all the skills of a senior developer
• Proven track record of successfully built projects
• Focus on a small problem while maintaining a bird's-eye view of the different moving parts of the software
• Gain buy-in for his ideas from other developers
• Explain complex things in a simple way
• Incorporate new ideas to solve new and old problems

5- What is expected of a CTO

• In addition to all the skills of a software architect
• Transform business goals into software goals easily. The "easily" is important here because if it takes him a long time to set the software goals it will impact the company's performance in the short and long terms
• Understand the position of different business parties in the company and its ventures. Be it investors, owners, customers, managers, employees, board members, or suppliers. Balancing the motivations of each must influence his decisions. Every day he brings some of these stakeholders into the fold while alienating others in order to meet the company's quarterly goals
• Is well-liked by his previous employers and has influential contacts that aid in the company's growth

6- Conclusion

This video explains my thoughts on what it is to be a senior developer. I presented it at a workshop a few years ago when I was a senior. Watch

My views have changed since then. I used to think that senior developers were just junior developers with added leadership soft skills. This is only partly true because a very important difference between a senior and a junior is dependability. The ability to consistently perform requires more than discipline, listening skills, and control. It requires a much more solid understanding of the complex processes within the software life cycle. The most important influencers of a task are: Language, existing code, fitness of the other developers that will be integrating with the task, planning and pre-existing requirements, and parachuted tasks mid-development. A senior developer has to perform well at all times regardless of curve balls, within reason of course. So he cannot take too long to think about whether or not to add the DB code for a small fix in the controller or the model, the decision must be made quickly using his experience and it must be correct more often than not.

The roles of a software developer throughout his career change greatly from one phase to the next and keep in mind that this is just one example of the basic roles. Some CTO jobs are required to be more hands-on with development like in startups, while others require more out-reach and influence like the CTO of an incubator. Just like some senior developer jobs require much more coaching and code review than actual development. Ultimately, the more one understands the processes around one's self, the better one will be able to manipulate them to one's own advantage. This list represents my own experience over the past eleven years. Your mileage may vary.