d1rk.com

d1rk.com


In der Bewegung liegt die Kraft

Dirk Brünsicke is software architect, open source developer and helps companies tuning their efforts in creating and maintaining digital products.

Share


Tags


bruensicke.com GmbH

Twitter


How to be(come) a senior developer

Dirk BrünsickeDirk Brünsicke

never stop to play

Do you know how kids learn? They play. They never stop to play. If you want to improve, you should always use new tools and toys. Play with them. Find something that motivates or interests you and play with it.

follow your idols

Find the one, who work on the software that you use. Find developers on social networks like twitter and github to follow them. Find out, who they follow and follow them. You will instantly get more information about what matters to you and your daily work.

know your tools

The difference between an amateur and a pro is, how they know their tools. It certainly works if you just do it, like you always did. But you will not learn anything going that way. Also, you will probably miss out new ways that are faster, easier or just more convenient. You should give new IDEs a test-drive, inform yourself about the servers your software runs on and also about tools to profile your code.

solve problems without code

You learned to code. And your title is software developer, so that should be the thing that you are supposed to do: develop source code to solve problems. The truth is: that is utterly wrong. If you can find problems that can be solved without creating code (that may contain bugs, i warned you!): do it. The best developers rarely create code but arrange things like that, that everything falls into place like magic.

use the cli

You probably started your career with a windows box. That is fine. But you should consider using bash (or zsh if you hang with the cool kids) to understand how (web)servers work and how they are configured. Scripting the hell out of your workflow minimizes tedious tasks. If you then finally switched to a
*nix based OS, you are one step closer to become a senior. Cygwin you say? Well, if you want to be a faker or clown, go to the circus instead.

understand components

It is totally ok, if you do not know all the available packages and server deamons that are out there. But you should know more than just apache and mysql. There are so many cool things out there, that even if you do not need them at the moment, you should consider testing them. Whether it is mongodb, redis, nginx or xx. All these tools solve one problem you may already have or face later on. And while getting to know them, you will certainly learn something.

engage

Go, create an account on github. Even if you do not do open source, you should follow the libraries and frameworks that you use over there. Start tracking what other people use with your favorite framework and learn from them. All the developers out there have similar or identical problems and needs. You will be wondered how much of them found or created good solutions that will help you cope daily work.

sharing is caring

If you happen to use and understand a piece of software that is open source, chances are high that there is something that you would do a bit different. Or you have an idea how to improve it. First, you should check if other people having the same issues. Then, probably they go a different route, that you never heard of, but is actually better than your way. Or, you just found a good way to improve something that is there. Go ahead. Fork the project, invest some time to find out how to solve your problem and start a pull-request. You will learn a lot while doing so.

motivation is key

Daily work bores you? You feel that nothing changed over the last 6 months? You are doing it wrong. But fear not, help is near. The internet is full of people doing weird stuff. If you are interested in 'something' it is most likely, that people already created projects about 'something'. Have a look, play, experiment and give back.

know your surroundings

A senior developer is not only experienced in creating code. He is also at least good up to a certain point at everything else related. Depending on the size of your project/company you should know what relates to your work and how that fits in. You should know what marketing needs in order to create a press release or if you work in a highly specified field, you should know what the people drives, who use your software to better understand what they need. Guessing features that later on will be requested helps in planning and designing your code.

craft with care

It is not enough to create code. You should craft it. Every line of code you create should be considered false, evil or buggy. Let your confidence go and double check with others how they think, your code should be laid out. Double check words and names of variables, classes and functions. Make sure, that what you did can be easily grasped by others contains appropriate documentation. Do not think: "other guy can ask me" - or even worse: "there is no other guy". You will be other guy one year later. You are then stuck with messy code without documentation when it breaks, right in the middle of a holy night.

sleep well, eat healthy

Developing software requires your attention and can only be done while being highly concentrated. Nobody can do that with too few sleep or an unhealthy condition. Make sure all your body and soul related topics are in order to focus on what you are doing. If you think of your profession like a pro, you will turn off everything that can draw attention to something else, than your work.

practice

Whether you are a dancer or a writer. Practice is, what is needed to reach a certain level of skill. This is the same for every profession. If you want to be a real pro, go ahead and do things more often to improve on them. Reflect more often to understand shortcomings of what you did the last time and see, how other people approach your problem.

server logging + monitoring

To understand what happens on your server where your application is running reading log-files helps. If you do not have log-files: yikes! Change that. How the heck will you know if something goes wrong or what does actually happen, without having logs? That was a rhetorical question, dude.

configuring and setup servers

Use shell scripts or provisioning tools like puppet or chef. It is absolutely not an achievement, if you just managed to manually install a certain stack on a server, but you are not able to re-produce it without going through everything again, step-by-step. Think of every server as a dispensable, rented vehicle that can and will be exchanged every now and then.

watch carefully

You should know, there are a lot of people that are doing great things. You can eventually learn a lot from just seeing how they are doing things. So, start to watch other people code and/or solve problems. The ones, that are better than you will teach you things. The ones, that do worse may need a tip or some feedback from you. So, start to teach them, what you have learned and get momentum about your passion.

reflect

Nothing is better to learn something, than teaching it. To reflect on your own code, read it, document it. Try to write things you already did a little bit different. Just for the sake of learning something. Find 2-4 alternative implementation methods that do the same thing, but using a different approach. Benchmark them against each other or choose the one, that best fits your style.

code is your enemy

Most of the time, producing code is a good way to achieve certain things: But use this as a last option. First, try to cope with the facing problem in a organizational way. Then, try to utilize an already existing library. If you really go the way, to implement it on your own, then do it right. Think the problem through from start to end. Find the correct terms. Build a small library that fits exactly that use-case and use that, instead of writing code, that is tightly coupled with your application code-base.

documentation

Because you do think in libraries and just use and connect them in your applications business logic, you will certainly need documentation for that. If you build that library on your own, you have to document it. Do it. Not only for the others, but for yourself as well. You will find implementation details while documenting it, that should be done a bit differently. Or can be improved by just adding a small thing. Then, you start to create code not only for a specific application but for a developer as a consumer. Be the first developer that consumes your library and make it a success for yourself. Then, tell others about it.

Dirk Brünsicke is software architect, open source developer and helps companies tuning their efforts in creating and maintaining digital products.

Comments