This is not about the purpose of our existence on the planet Earth, but about why do businesses keep programmers on the payroll, you probably will not like what you read, you will be uncomfortable but (hopefully) it will make you think about your work in more business way and also be more agile (I know, I know).
Why are we on the payroll
All businesses have one goal: to make money period. That means earning more money than they spend. Therefore, you are only useful to the company as long as you are also earning more many than you cost (I know I am making oversimplifications, but this is just to make a point, you can stop the flames, thank you). So, the only reason that you are on the payroll of your company is that someone, somewhere either knows or thinks that it's true and you are bringing more value that you get paid. What this means is that you need to be as efficient as possible to actually deliver on that promise.
The first thing I heard on my new job
I started my current gig on April 1st 2009. I actually have a thing for starting jobs on the 1st of April. On my first real job I worked for about 2 months without a proper contract. Towards the end of the second month I was seriously considering whether or not this was a huge April fool's joke on me. Happily, it was not. So, anyway, the thing that I heard on my entry interview at my new job was: you are not hired to write code. And an alarm went off in my head, screaming: WTF?!??!??! I have 5 years of commercial experience writing software, and they tell me I am not here to write code??? Have I just made a huge mistake? What followed was this: you are hired to solve problems. Business problems. And that hit the nail on the head: we, as programmers, are meant to solve business problems. The fact that we are most often doing it with code is just a side effect. If you are able to solve a problem with Excel, do that in Excel and don't write your own custom software to create diagrams from csv files or whatever the case may be.
You are not your code
How ofter you have the experience like this:
- browsing through some random code
- notice a seriously messed up crap
- git blame
- it's my code
I have that every other day. It means a couple of things:
- I am developing, because I would not write a code like that now
- makes me humble, I make mistakes, a lot of them, and this is a proof
- that code works in production and delivers value for some time already
The point is: you are not your code. All of the SOLID principles, software craftsmanship, deisgn patterns and all are important. But what beats them is: delivering business value. You should strive to have beautiful code that delivers value, but if you have to choose, optimize business value. In the longer run this is what business evaluates. Perfect code that sits on the shelf and is never used, brings zero value and is actually just a cost. Actually, on that point, all code is a cost. So the less you write to solve business problem, the better. Just make sure that you do solve the business problem.
Lines of code
What all code has in common? (With the exeption of extermely short pieces of code) it has bugs. The more code, the more bugs. Therefore each line of code that you write is a liability, not an asset. Think about it as a debt to the universe. You need to take that debt to solve your business needs, but don't take too much of that debt, because you will go bankrupt. Most of you (I hope) are not evaluated based on the number of lines of code that you write. I sincerely hope that you are evaluated on the number of functionalities delivered or business problems solved, not lines of code. If that is not the case, you are at a wrong place.
Most valuable pieces of code that I have seen are usually utter crap to read, and even more difficult to maintain. But they work for years in production without people needing to touch them. So, count problems solved, not lines of code.
By which I don't mean software development, but personal development. You have to develop your skills throughout your entire career. We have chosen a career of constant learning, till you retire. This is actually true for all careers nowadays, but it especially evident in software engineering. New tools and technologies (databases, languages, cloud, etc) appear every single day. We constantly need to learn new tricks and be up to date with the stuff we are using every day. If I used just the skills I learned in university, I would be out of a job right now. Those skills are mostly useless. I did not use java, knew nothing about agile, did not know git, svn... The list goes on and on. And you can wait for your company to train you. I am sure they will. But only when they see that you are almost useless without a particular skillset. So, if you want to act like a responsible adult, you should actually be proactive about that and do it yourself. There is a lot of free courseware available online, free lectures from MIT, Carneggie-Mellon, coursera or Khan academy. You can find plethora of information on any topic available online. You just need to take advantage of this, and train yourself. Note that this trainign needs to be beneficial to both you and your company. It needs to lead in increases in (you guessed it) profit (more efficiency, better design, less bugs, you get the gist).
Recently, many books have been published on the motivation of the people doing cognitive tasks, such as drive. You can also watch the video to get the gist. Research shows basically, that the "carrot and stick" method does not work for people doing cognitive tasks at work. What does work is: autonomy, mastery and purpose. For the autonomy and purpose, you will have to figure this out on your own, but for mastery, I can recommend contents of a couple of books:
- Pragmatic programmer. Even the title says it all: "The pragmatic programmer. From journeyman to master". If you are only just starting, read this book. It has all the right tips for beginners and should be a required reading for CS students. If you have experience, you will find a lot of this obvious. Bare in mind that it was not all that obvious 5 or 10 years ago for you.
- Code Complete 2nd edition. This is the ultimate book on software construction. IT is lengthy but very well worth the read.
For the java folks also these two are required:
- Effective java. A bible for anyone using java the language.
- Java concurrency in practice. If you are writing concurrent programs (and we all are), you have to read this book.
You work 40 hours a week. This is about 35% of your conscious time. And this is the aspect of life, that your livelihood depends on. Invest in it! And if you treat it as an investment, follow the advice of the financial investors, do it often and regularly, make it a habit.
Reading a technical book does not take a long time. You can alternate between fiction and technical books. You can subscribe to RSS feeds of some technical blogs, you can listen to podcasts on the commute. My point is: there are a lot of ways, in which you can learn, using the time you have. Do it.
- the stuff that supports you right now. For me that is java ecosystem and postgres. I subscribed to a number of feeds from dzone, plus planet postgresql. This keeps me up to date with the stuff that I am using day to day.
- new stuff. The stuff that you are not using (yet?). Again: a couple of feeds from dzone, some random RSS stuff on python, nosql, hadoop etc. This brings serendipity. From time to time you should discover things that are useful to you in new problems from this stream.
You can use G+, twitter, RSS, whatever. Just try to stay at least somewhat up do date with what is going on in IT.
You should also stay up to date with your business context. A lot of the time, there are huge benefits in changing processes rather than tools. And engineers are good at optimizing things. So you can be a hero for just changing a process and not code.
And please don't become a trainer of white transsexual rhinos (trademark of one my friends). If you are only a batch process engineer or a webservice developer you will be reduntant once that need is gone. Try not to get boxed and don't box yourself. Never label yourself that, be a capable software engineer that can solve any problem. That is what ultimately gets you job security.
Crisis will come
Whether you like it or not, I believe that the compenstation level in IT in not going to last. I think that the current situation is a speculation bubble created by large demand on the market. People that come just out of school may not realize that immediately, but I still remember how hard it was to get a job in the peak of the bank crisis, when all banks laid off a lot of people, who were all looking for a job. If you follow the advice above, it will be a lot easier to switch jobs, you will have up do date knowledge, you will know tools that help you solve a large variety of problems. You should be a perfect candidate for any gig. And you should also have the possibility to take a pay cut for some time at least.
Think about your future, chances are you are not going to be working in the same place in 10 years. At the very least, you should be able to answer youself the question: what do I want to do in 5 years? When you know the answer to that question, you should create some rough plan on how to get there.
I like the English origin of that word. Polish counterpart comes from the word "price", which is missing the point. The reason people get hired and fired is sometimes the price (as was with massive outsourcing to India), but more often will be the value that you get for a dollar spent on the salary. You should optimize the value that you bring. As a though experiment: think about how many products does your company have to sell (or how many customers have to pay their bills, or whatever is the income source for your company) in order to pay you. And then think, if you are bringing more value.
Programming is not about typing
it's about thinking. So, first, solve problem, then write code.