What IT does feel like

What IT does feel like

This will be a series of blog posts ... this one will not cover a lot of ground. To get an idea of what you would be getting into you should think about what studying, what your private life and what working will eventually feel like.

Studying:
You might want to study at home: reading articles (following RSS feeds), getting an idea of what the big picture looks like, joining courses (e.g. https://www.coursera.org) and communities, looking at other people's code and starting personal projects.

In college or at an academy: This will be a lot like school as you know it. There will be some very abstract and technical material that you have to study. There will probably be some projects that you have to work on. There will be things you need to learn by heart and most of the material is stuff you will never need after you graduate.

Private Life: don't underestimate this part. You commit to a certain degree. You will spend a lot of time in front of the computer. "Just doing it as a job" is not a great idea. If you do not want to bond more with your PC ... you can probably still get a job but your options are a lot more limited, then. Other people will know you as an IT guy. That is a label worth thinking about because there are a lot of assumptions that might be annoying at some point (every IT guy can help with that virus ... or set up a local network in a few minutes. Right?).

Working: A big mistake to make is thinking that once you know how to program you will primarily apply that knowledge and write code most of the time. The truth is that the biggest part will still be research (reading API documentation, reading the existing code that you are working on or reading material that describes the problem domain*). Another big part will be trial and error to see if your approach works. In many cases you will also have to come up with a software design before you start coding and you will do testing as soon as you are done.

A good programmer will write as little code as possible. If people tell you they write a lot of code all the time, then chances are they (or their company) have not found the most efficient way to solve the problems at hand or that they work in a huge company where all the tasks mentioned above are given to highly specialized people.



* When you write software that creates value there are always two domains: the problem domain (in what concepts do your clients think, what terminology do they use) and the solution domain (what tools and methods do you use to write software and solve the problem).
A good programmer should be able to communicate using the vocabulary of both domains. A good project manager should mostly know the problem domain and have a rough idea of what the most important solution domain concepts are.
A pure tester should not have to worry about the solution domain because that creates a bias or confusion.