9 Years of code

I wrote my first hello world in Java in 2012, at the university. And I want to share few thoughts that I have changed over these years.

Who I am?

Should I be considered a programmer? an engineer? or a developer? We can discuss a lot about that. But I do not really care. What I really care about is: What is my profession about? And by profession, I mean “generating software in the software development industry”.

So, What is my profession about?

Well, when I was in high school and I had to select my future path in the university, choosing a career, I was wondering what is the “computer science engineer” daily life looks like? But I didn’t get any real answers to that question, at that moment.

Nowadays you can find on YouTube: “One day in life of $CompanyName Software Engineer”, and get a little approximation about what a job looks like. But probably you only geet “cool companies” or “dream jobs” videos. But in my experience, this is more a superficial approach and no a very realistic one with the day-by-day on projects, challenges, and the “first person view” of the job.

In my experience, these are the 5 most important things that I had changed over these years about what I think that was and what really is this profession about:

1. It’s about dealing with people more than about dealing with code.

Think about how many interactions you have in the day with people. So the most important skill is here the communication.

In the daily work we are constantly dealing with people, through emails, project meetings, team meetings, making pair programing, reading code written by people, interacting in pull requests, in conferences, solving issues, etc.

You communicate with other all-time, by coding, with the business, with the customers, with the team, with yourself… all is based on comunication. Improving this skill has the biggest scope and impact.

2. You are the only one responsible for your path.

• University is not responsible.
• Your parents are not responsible.
• The government of your country or the politicians are not responsible.
• Your company is not responsible.
• Your team is not responsible.

Only you are responsible for your own learning road and career path.

Note: But, being the only one responsible for your path does not mean that you have to go it alone 🙂. There are communities and people willing to help and to be helped.

3. Projects are about delivering value taking account of the customer. More than money, contracts, and code.

• Learn why projects fail.
• Learn why software fails.
• Learn what is important to the customer.
• Learn what is important to the company.
• Learn what is important to the team.

Money and contracts are important, but customer collaboration is still more important. At the end of the day, you will find that software brings value to customers by solving problems. But maybe, customers, companies, and teams have different “expectations” for the project.

If you build the right software at the right time you potentially can get much more profit and future profit than delivering useless code.

4. Problem over Solution

The objective is not to implement beautiful solutions based on theory. The center tactical skill of your career should be to develop the ability to deal with problems and not creating solutions.

To deal with problems you need to take into account a lot of factors based on context: requirements, non-functional requirements, schedules, technical debt, real customer needs, tech strategy, team consensus, concurrency, security, laws, team culture, the company strategy, etc.

The ability to fight against a problem, orchestrating all these variables and asking the correct questions in the correct order and at the correct time, is based on experience.

But what about solutions?

Knowing solutions made by others is important too. Undestanding the why of the solution and the how, makes you to be more fluent with specific kind of problems. The same happends with other’s failures.

In general, the more problem-solutions you experience, the more possibilities you have to deal with a problem in the most effective way.

5. Do never keep away from the code.

As said previusly, most part of the time you deal with people and some of the rest you deal with code. While the time you deal with code you spend most of the time navigating and reading code more than writing or refactoring code.

At this point of the post, you may be thinking that code is just the worthless part of this profession… but that’s not true. Writing high-quality, testable, and clean code is what is expected from you as a professional. Companies will assume this. It’s your obligation to master this skill. In the end, the code is the central building block of value in software projects.

Never forget how to code and conserve this mastery. No matter where is your current role or position. If you forget or get away from the code, you get away from the trenches, you get away from the key building block of the software system, and you lose the real connection with the problems of the team and the company.

In general, you should never get away from what you love.