10 years in business 🎉

Ten years ago I started my journey as a professional software developer and earn real money for coding 💰

On the 1st of October 2007 (at least I think it was the first, but it can be the second or third too), I began my internship at IT Services Hungary in Budapest.

This is my reflection on my 10 years as a “pro.” I want to share what I’ve learned in these years.

Branding

One thing is that you get branded. As soon as you accept your second job as XYZ developer[1], you get branded. This means, you know the language XYZ very well, and even if you want to work with other languages, it won’t be easy because companies hire you for your primary skill: XYZ.

I branded myself as a Java developer a long time ago[2]. But I think it was not a wrong decision because there are a lot of Java positions — at least in Austria, where I work.

But do not worry! It is possible to get your brand changed. You only need to work at a company which specifies for projects in different programming languages, and you tell them, you want to do this other fancy language because of whatever reason.

If you work at a company which focuses on a particular language or skill, things get harder. It is not impossible, but it is not easy.

For example, I like Python and functional programming. The company where I work is specialized in Java and .NET solutions. Not really an option to switch to try my other sides too, but I’ve talked to my manager and told him that I’d like to try Python in a real project. He acknowledged this and knows that if a (potential) customer asks for a Python solution/developer, he can say “Yes, we have someone.” instead of turning him/her down.

As you see, branding is a thing but you can be assertive and can re-brand yourself.

Salary

Know what you’re worth!

It is not easy to find the right salary you should ask for. At the beginning you underestimate yourself, and then you think you are worth much more than you get. Discover the balance.

You start by selling your time. This will change with time because you get experienced and will learn shortcuts, time-optimization and you can achieve the same goal with much less work. In this case, time-based pricing doesn’t pay off, you have to change to value-based pricing.

If you are an employee, you get this by salary raises. If you are a freelancer, you can get this with increased hourly rates (even though you shouldn’t sell your time, but this is how it works) or greater prices for project completion.

But remember: money is not everything! There are things you cannot buy with money.

Be humble

No two people are equal — and this is true for knowledge too. If you learn, do your work, you gain experience. Sometimes you reach a level your co-workers already achieved, at times you get a better understanding on some topics than they do.

Now if someone asks you, or struggles with a question, remember that you needed guidance too. In these cases be humble and answer their issues and avoid remarks like “This is pretty easy, I wonder you do not know this!” How would you feel if you ask a question and someone would answer the same way?

Be assertive

Sometimes you know better. Not just because you are the best developer ever but actually. You know, that your architect/solution engineer/mastermind will create something with the wrong approach/tools.

In this case don’t be humble and shy but be assertive! Tell him/her/them that they are not exactly correct, but you know a better solution you should try. And say what’s the flaw in their thinking and how can it be made better.

Be assertive if you want to make your life better. It is not an option to endure small office spaces, noise and other things which disturb you in your work. Some problems can be solved easily (noise-canceling headphones), others need a talk with your management.

Do your work like a pro

I think this is something you already know. But let me summarize it:

Know your language, your tools, your team and deliver on schedule.

Ask!

You will not be a pro until you learn how to ask. In the beginning, you have to overcome the fear of asking, because you feel ashamed that you have to ask how to, for example, open a database connection with Spring.

As time goes by, you will learn how to use the available tools like Google and Stack Overflow, because every developer uses these online wikis for his/her daily work. Naturally, the basics will stick with time, but if you do not exercise these “muscles,” they get weak, and you have to re-learn.

Learn new things

In our profession, you have to learn new features of a language[2], new tools, new frameworks and so on.

But in general, it is a good idea to learn something new every now and then. It opens up new worlds, new options you could embed in your own coding habits.

This is why I learned Python, functional programming, Elixir, Frege (and Haskell), Ruby, Phoenix, and much more. It is fun to learn — if you have time and can walk your own pace.

Teach

Nonessential at a school but that is a good option too. The core idea is to share what you’ve learned because it sticks better and you learn it better. If you cannot explain it to anyone, you do not know it well enough.

The easiest way of sharing is at the coffee machine in the office space. Talk to some co-workers and tell them what you’ve learned.

If you want to go further, start writing a blog, share code, create online courses, speak at a (local) meetup or conferences. Even if it doesn’t earn you money, you will earn knowledge, respect, and appreciation. And you can make new friends.

Get yourself a life — avoid burnout!

Some might say, a real professional developer has to breathe code 24/7. This is not true. If you are a real pro, you can do your work in your working hours and relax after.

For me, one type of relaxation is writing code — but not for work. Just for fun. I pursued this fun coding for a while to get even more money out of smaller side-projects but then I realized that I have had no life, no free time and my thoughts were occupied by those side projects and their deadlines. After a year or so I said “NO!” and quit my side projects.

And if you have a family you have to spend time with them. Working hard is not an excuse. You do more harm to your peers if you neglect them than bringing home less money and cannot buy them the new iPhone Y the next day it hits the shops.

At least I value time with my wife more than work.

Something technical

OK, the above sections were mostly about soft skills. Now I share with you what I appreciate in the hard-skills section after 10 years of a Java Developer[3].

Tests

The most important thing in my eyes is tests. If it is TDD/BDD/ATDD or test-after, you should write tests. It is a superb safety-net for your future work (extension, refactoring). For a test-after approach let someone else write the tests or forget the code you’ve written when you write the tests!

Naturally, sometimes the tests can be written badly. Once we had a developer who created some calendar-based evaluation rule, he has written the tests, and everything was green. Until one day the test went red. We didn’t care because it was on weekend and Monday the test was green again. Then the same thing happened later too — but we didn’t care because the next day (yes, daily builds FTW) it was green again.

By the third time, I investigated the issue. The result was that the code had an error — and the test was written to the code, and it had a bug too which came to sunlight only at the last day of the month. The solution was to discard the whole code inclusive tests and re-write it. Because it was a complex logic and I’ve had time I’ve used TDD.

Build tool

Get yourself a good build-tool with dependency management.

At the university, we used simple “add the JARs to your project in Eclipse” if we had any dependencies in our little projects.

At the beginning (in 2007) we used Ant. It was not bad because I could create automated build scripts for my projects, it executed tests too. The downside was the dependency management.

It was a real game-changer when I learned about Maven. Dependencies available online, the tool downloads everything it needs, with the right version and everyone is happy.

CI

After you have a build tool, you can (actually must) create a CI environment where your code changes are automatically compiled and, most important, all the tests are executed. This ensures that the codebase, at least what has tests, works as expected.

IDE

I don’t have to mention it, have I?

And IDE is the base for every development. If you work in a team (what you should because it is fun and more productive) you have to aim to work with the same IDE. Not just the tool itself, but the same version, same configuration, same keyboard layout.

Why? Because it makes easier to pair[4], get some help, find why you do not see those nasty linter warnings Jenkins spills out.

Use Open Source

DRTW![5] Use open sourced tools which have a lot of knowledge well tested available for your projects. For example, Apache Commons is a real winner for IO or just pure Java language basics, like toString, equals or hashCode generator.

Do not be shy, if the license gives permission, use it in your project. It saves you time, and you get more pro.

Conclusion

Ten years are only the beginning. I am 33 now, still have at least 30 years to go. I plan to code in the following years, but I know that it is not just about coding: I have to share my knowledge with others to get the flow. Let’s see, what I can achieve. Next reflection comes after 10 other years. Stay tuned!


[1] XYZ can be any programming language (Java, C#, Ruby, Elixir, or Piet), or technology-stack. Choose anything.

[2] Not true for FORTRAN and COBOL developers, of course.

[3] Yes, with a big D because after 10 years one deserves a big D :)

[4] OK, pairing is not the best example because who sits at the computer shouldn’t think just type. But if you switched shortcuts then it can cause unwanted results.

[5] Don’t Reinvent The Wheel!