Previous |
Next |
My knowledge of what it is like to be a programmer is gained from working in Australia and the UK. Things change over times and they differ from one country to another. An easy way to find out what it is like being a programmer where you want to work is to do some searches on Job web sites. This can be very useful in finding out what the demand is for different combinations of skills what the pay rates are like and all the other subtle differences in job vacancies. Every so often I read of someone claiming that there is no demand for skill X or huge demand for skill Y. The easy way to refute or confirm these statements is to go to a job web site and do a search. So at the time of writing some trivial research at www.jobserve.co.uk tells me that there are slightly more adverts that mention Oracle than Java and many more adverts mentioning Java than C#. This implies that if you are on the Job market with a combination of Oracle and Java skills you will probably be able to find employment.
There are a lot of books available that tell you how to write computer programs, and plenty of book about managing software projects, but not so many that tell you what it is actually like to be a programmer. Of course it can vary wildly between organisations and in some organisations the cartoon character Dilbert is not considered fiction. There are some common characteristics between diverse programming jobs. One of the puzzles of the life of a programmer is that of job descriptions. I like the term “programmer”, it gets to the heart of what you expect to do. However many people think the idea of being “simply a programmer” somehow demeaning, and some people even use derogatory terms such as “code monkey” to imply that programmers simply churn out lines of code to order and are incapable of the more abstract tasks such as the analysis and design of computer systems. To get away from the view of programming as a lowly task people invent all manner of fancy titles to try to “big up” their role in life.
So you have the idea of the analyst/programmer, someone who both analysis the problem and then creates the code to solve the problem. There is also the generic term engineer, which for me brings to mind a person doing things with physical stuff and using tools like screw drivers, welding kits and lathes. Other terms are developer, software engineer, and things even get as grand as Software Architect, which tends to annoy the real architects who spend many years of dedicated study to be allowed to design buildings. In reality you are probably either a person who writes code or a person who spends their life mainly in meetings. Personally a life in meetings is my idea of hell so if that means I am viewed as a code monkey, that's OK by me.
The reality of the most programmers lives is “life in the cubicle farm”. They are regarded as a cost to the organisation rather than an asset and are given the minimum resources necessary to get the job done. This means a cubicle, a computer and a phone. Having said that in the late 1990's I worked at a place where we had one phone between 13 programmers. It didn't trouble us too much as we tended to communicate via email, but it did rather show where we were in the pecking order . One of the problems of being a developer in a big organisation is they sometimes treat you like a non technical person. Thus the firewall might block off FTP access and your development tools are not allowed to connect to the update sites. If you are lucky the organisation will realise that you give them control over their most precious resource, their data and they will treat you like an asset. Another problem is that the IT department may want to give you a standard PC that is suitable for running MS Office and browsing the web but hopeless when running a full strength IDE and compiling up a vast program consisting of many modules.
In most organisations I have worked for the programmers were not required to wear a suit. There was an acceptance that they could dress in a smart but casual manner, sometimes this might be as smart as “no jeans” and in other places you could come as shabbily dressed as you like so long as you produced the code. Most programming jobs are nominally 9-5, or similar hours and most private sector jobs do not seem to offer “flexi-time”.
However some organisations operate an assumed culture of “presenteeism”, whereby your devotion to the company and your chance of getting ahead will depend on spending as many hours as humanly possible at your desk apparently working. My general advice if you find that is the culture of your company is “flee”, unless of course there is a very, very good chance of getting share options that will make you very, very rich. There is more to life than programming, even if you love the job, the job won't love you back. Life is not a dress rehearsal and there has never been a recorded incident of anyone on their deathbed saying “I with I had spent more time at the office”.
I have been a commercial programmer for over 15 years for a wide variety of organisations using several different programming languages. One conclusion I have drawn is that the majority of organisations are not well run. Given the choice between doing a job well and attempting to do a “quick and dirty” job most organisations go for the “quick and dirty” option. I have come to the conclusion that a quick and dirty job is always dirty and in the long run is never quick. Perhaps it is a trite summary of management speak but if you cannot afford to do it properly the first time, how come you can afford to do it twice.
There is a whole discipline and body of work about how software projects should be run, and a wonderful sub-genre of books describing software projects that go horribly wrong. I love reading these books for the shudder of schadenfreude, or pleasure at other peoples discomfort. Time after time organisations make the same mistakes and go horribly over budget and frequently have to cancel entire projects after spending huge sums of money.
One of the most famous books on software development projects is “The Mythical Man Month” by Fred Brooks. This is an excellent and very readable book, I recommend it to anyone involved in any management, even if the projects have nothing to do with software or computers.
As you can guess from the title Mr Brooks does not think that the amount of time a person can work in a month is a simple numerical quantity that can be used to calculate the time a project will take. One of the key rules that Fred Brooks states in this book is “adding more programmers to a project that is already late will make the project later still”. The reason behind this apparently contradictory idea is that each new employee will incur significant overhead in terms of “coming up to speed”, communication, training and all the other myriad things that will distract the currently productive employees. Despite this very well known principle on several occasions I have been told during interview that I was being employed because the project was behind schedule and they had decided to “throw more bodies at it”.
Unless you are lucky or have been employed by a newly set up company you will probably not have much choice in the tools you use. So you may be recruited for your ability to program Java using Hibernate and JSF, but if you have a background with NetBeans and the company uses Eclipse, you are probably going to have to get used to Eclipse rather than being the one programer using a different IDE.
In the world of Microsoft tools development there tends to be just one way to do things. You buy the Microsoft development tools, the Microsoft source management system and use the Microsoft libraries as the base to build your systems on top. The Microsoft tools change as the years go by, but in essense its a simple choice. The world of Java tends to involve more decisions, more choice, more possibilities. In capitalist societies we tend to think that more choice is always good. The longer I deal with Java the more I think that a little restriction of choice can sometimes be a good thing.
Most of your programming time will be spent in front of some type of editor/IDE. Probably the three main possibilities are Eclipse, NetBeans or IntelliJ. The product you end up using is usually not down to which one is technically “best” and more to do with what is most widely accepted or what the rest of the team is using.
Whilst they all have a great deal of functionality in common, if you are really comfortable with Eclipse, starting at a NetBeans house means moving slightly out of your comfort zone. Then there is the issue of source code management tools. If you have more than about two programmers on a project and they do not use some type of source code management, my advice is to flee at once, these people are not serious about their work.
The history of software development is the history of new methodologies. Because software projects are constantly going over time and over budget, smart people are constantly trying to come up with new ways to ensure that projects go according to plan. In the nature of commerce each new methodology tends to be over sold by its creators. Every new way of working is promoted as “the silver bullet” that will guarantee success if it is just followed absolutely. I remember being taught that if developers followed the particular methodology in fashion at the time they were guaranteed success with their projects.
When I first went into programming the buzzwords of the time were CASE and 4th Generation languages. CASE was an acronym for Computer Aided Software Engineering. The idea that as computers were so clever, why not use the computers to actually create the software. The idea of 4th generation languages was to create programming languages that were significantly easier to use than the existing languages so that non programmers would be able to create software and so that existing programmers would be more productive. Neither of these ideas were a “silver bullet” that made creating software trivial, but they have both left a legacy of improvements in the way software is created. As tools and techniques improve business people tend to expect more from software. Whereas at one time management was impressed that they got a report on sales from the database, today they expect to be able to give the criteria for the report and to have several different types of graphical representation and to have the report run and printed in the time it takes to make a hot drink.
One of the problems with methodologies is that those who create and sell them treat software creation more as a science than an art, and there is a great deal of art that cannot be tied down to a prescribed set of rules. One of the widely promoted methodologies of the moment is called “Extreme Programming”. The fact that it uses the word programming rather than using a word like engineering, architecture or development shows that it is moving away from much of the history of development theory. I'm confident that Extreme Programming is also not a “silver bullet” but it is worth researching as an innovative and fresh approach to creating software. Extreme programming moves some of the creativity back from the analyst and to the lap of the programmer. It has a very strong emphasis on writing tests and for releasing software to the end user early and often. This is to get around a perennial problem of the past that analysts spend so much time completing requirements documents and designing the software that by the time it is finished the customers have changed their minds, or there were huge misunderstandings between what the customer said they wanted and what they actually needed.
Perhaps more important than software development methodologies is the idea of Project Management Approaches. One of the important benefits of Project Management Methodologies is the idea of giving everyone the same vocabulary. It is amazing how people can use the same words yet have a different understanding for them. In UK government circles the PRINCE2 approach has become dominant and it is a fairly large tick on any managers resume to have gone on the basic PRINCE2 accreditation course. If you are in an organisation that offers you the chance to do a PRINCE2 course, grab the opportunity with both hands.
If you are lucky and you are involved with a well managed software project, how will you spend your days? Unfortunately you will probably spend a surprisingly small amount of your time actually writing new code. You will probably spend most of your coding time trying to make sense of what other programmers have written. There is a good chance they will have left the organisation so you won't be able to ask them what on earth they were thinking of when they wrote such convoluted spaghetti that appears to make no sense at all. In theory people should write plenty of
Another depressing task is extended setup times. By this I mean that big software projects have large amounts of dependencies. Thus you might have a web front end that interacts with an EJB business layer and a requirement for just the right data to be set up in just the right database schema. The code you require will be stored in a source management system and in theory you should be able to simply check out the source code and start programming. In many situations the code simply will not build due to some broken dependency. For example someone has checked in a version of a module that has methods or exceptions required by some other module. This situation should not happen. When people check code in it should be done in such a way that a correct check out will build “out of the box”, but sometimes this does not happen.
Version control software VCS is vital for any project that involves more than one programmer, and you will need to get used to the product of your employer when you start a new programming job. VCS It allows the management of multiple versions of the same software. Thus when a member of the team writes some code that has an obscure bug you cannot track down you can simply revert to an earlier version of the code. VCS is used to prevent programmers overwriting the work of others. This can be done either by locking a section of code, i.e. ensuring only one programmer can work on the code at any one time, or by using optimistic locking whereby more than one programmer can “check out” the code but when they come to “check it in”, they are informed of the conflicts which they then need to resolve in order to ensure that the changes made by both programmers are incorporated into the final version of the code. Version Control is sufficiently important that some organisations have employees dedicated to the task to manage “builds” versions and the release of live versions of the systems.
VCS is well supported by free software with products such as Subversion and CVS and in the commercial world Microsoft Source Safe. Many leading Integrated Development Environments include integration with leading VCS products, thus Netbeans and Eclipse include support for CVS and Subversion..
Contract programmers have temporary jobs. They are experienced workers who are given a time limited contract, typically 3 or 6 months and at the end of that period the employer can renew the contract or allow it to elapse and effectively get rid of that employee with minimum fuss. For the employer, contractors come with the benefit that they do not represent a long term financial commitment and have much less employment security. In exchange for that lack of job security contract programmers are generally paid better than permanent staff. This can represent 2 or 3 times the pro-rata rate of the permanent staff. The reason I say pro-rata is because contractors have no rights to holiday or sick pay so they have to work out their actual yearly income based on less than 52 weeks of pay. So for example you might decide a reasonable rate is 47 weeks pay per year allowing for some annual leave, public holidays and the odd sick day or days between contracts.
For employers the theory behind using contract staff is that experts are hired in for specific tasks that the existing staff cannot do, there is a knowledge transfer to the permanent staff and at the end of the contract the task is complete and if similar work needs to be done in the future the organisation will now have the skill. It rarely works like this in practice and there are many, many examples of contract staff who have had their contract extended over many, many years with no knowledge transfer.
It might seem obvious that working contract is better than permanent because of the extra money but there are disadvantages. The lack of security can be a real problem. If you spend a few months unemployed between contracts it can quickly wipe out any financial benefits, and the lack of security can be a constant worry. When contractors are looking for a new contract it can feel like a game of poker. Do you take the contract that will involve living away from home but which pays more money or do you wait until one comes up closer to home. Do you take the short contract that doesn't increase your skill set but which pays well or do you take the longer contract that doesn't pay as well but will involve developing a new useful skill that might help getting future contracts.
In the UK most contractors work through employment agencies. The agencies act as sales people constantly phoning companies that might require staff . When the place a person in a contract role the employer pays the agency and the agency pays the worker an takes a percentage commission as a reward for getting the job. Some contractors resent the fact that the agency gets a percentage of their pay, but if you don't like that then you can always attempt to act as your own agent and do all the “cold calling” and selling that goes with the role of an agent. Being an agent is harder work than it looks.
If you start working as a modestly paid junior programmer, how can you progress, what is the career structure. Like many working roles the more successful you are the less you are likely to do the task for which you originally trained. Thus programmers often become analysts, or software designers or go on to manage teams of other technical people. This means moving out of programming and into management. Management requires very different skills to programming. It requires people skills, getting people to do what you want, to hit deadlines, to work with each other and occasionally to make tough decisions about hiring and firing. Working as a contractor is one way of slightly working around the conventional path as you can make good money but stay with the original aim of actually writing code but it does come with the price of lack of career security. In the end you have to accept that if you want to be highly successful, secure and financially well off you are not going to get there by staying a coder.
Previous |
Next |