When choosing what we want to study, and do with our careers and lives, we all have some expectations of what it is going to be like. Now that I've been in the industry for almost a decade, I've been reflecting a bit on what I thought (back when I was studying Computer Science) programming working life was going to be like, and how it's actually turning out to be.

My two biggest shocks (or should I say, broken expectations) by far are the sheer amount of maintenance work involved in software, and the overall lack of professionalism:

  1. Maintenance: At uni, we were all told that the majority of software work is maintenance of existing systems. So I knew to expect this in the abstract. But I never imagined exactly how overwhelming this would turn out to be. Perhaps it's something I mentally glazed over, and hoped I'd be building cool new stuff from scratch a lot more. But it really is the case that most jobs are overwhelmingly maintenance, bug fixing, and support oriented.

  2. Lack of professionalism: At uni, I always had the impression that commercial software work is very process-oriented and stringently engineered. I had images of ISO processes, reams of technical documentation, every feature and bug being strictly documented, and a generally professional environment. It came as a huge shock to realise that most software companies operate no differently to a team of students working on a large semester-long project. And I've worked in both the small agile hack shop, and the medium sized corporate enterprise. While I wouldn't say that it's always been outright "unprofessional", it definitely feels like the software industry (on the whole) is far from the strong engineering discipline that I expected it to be.

Has anyone else had similar experiences to this? What are the ways in which your expectations of what our profession would be like were different to the reality?

  • 4
    As a student almost out of the university, this is a very interesting question! Can't wait to see some answers
    – Mike42
    Commented Oct 17, 2010 at 22:30
  • 8
    What you're seeing now is the reality. Other fun-facts that also belong to reality are: billions of people without food, illiterate, under the constant threat of warfare, finance market nearing collapse, etc. In other words, college is a wonderful reality-distortion-field, and people can learn a lot of textbook knowledge inside the protection of this field.
    – rwong
    Commented Oct 18, 2010 at 4:06
  • You should expect whatever you want. If it turns out to be something less that what you expected don't accept that as reality. Be a trailblazer and make your expectations reality!
    – Atomix
    Commented Oct 18, 2010 at 18:50
  • 1
    I love programming. I hate the reality of how software is being developed in the "real" world. What you describe is a fairly accurate account of the state of affairs in the software industry. Commented Jun 24, 2011 at 19:37
  • As Fresh Jr.Software Engineer,I'm also experiencing this,I thought this is only in my country,now I'm getting its the Unwritten feature of Software Development.
    – parmanand
    Commented Nov 20, 2011 at 20:23

10 Answers 10


I feel you man. I just graduated little over a year ago in fact, jumped on the first job offer that came my way and got the biggest shock of my life.

Things I didn't expect:

School stress and Work stress aren't the same - The stress of working on a school project with friends, or working solo, even with that looming thesis deadline or special project defense does not compare to the stress of seemingly unreasonable work deadlines, communication problems, (a little of office politics) and crunch times.

Lack of Best Practices - Same as your experience on professionalism. Before taking my first job and during my training period, I rushed off reviewing and reading about best practices in both programming and software engineering. These aren't followed as well as they should for impractical and, to be fair, practical reasons. And sometimes, your knowledge counts very little against others who are merely afraid of the unknown and treat these practices with disdain.

What they taught in school was just the tip of the iceberg - Thinking that what I learned self-studying and from classes was enough to get me through, I was shocked to say the least as I stared dumbfounded at the first piece of code I was supposed to maintain. A lot of the skills I use now were learned on the job or during my job that I keep on wondering if I could've made it without a college degree at all. XD

The Importance of Communication - Made me realize what all those English classes were for. Before the real world, I could not see the relevance of having three to four different English classes in college when it's been taught since we were in the first grade. You're no use in your job when you can talk to a computer but fail to talk to people.

  • 5
    +1 The importance of communication. As for #2, it is not the lack of best practices; it's (i) too many best practices, and (ii) prevalent lack of interest in following any.
    – rwong
    Commented Oct 18, 2010 at 6:52
  • 1
    +1 for the tip of the iceberg! So many graduates think they know everything, now I feel I know less than ever!
    – billy.bob
    Commented Oct 18, 2010 at 20:45
  • +1 Some good points here. Often the reason for the lack of best practices/systems/procedures is up-front 'cost' (i.e. requires capital expenditure to purchase) - but the price for not having them is increased maintenance or, worse, product failure through runaway bug lists or not satisfying requirements.. which good communication could help to avoid :-) Commented Oct 18, 2010 at 22:50
  • 2
    I like this answer. It's a good one. And it makes me wonder: why isn't there some sort of "internship" like all medical doctors have to go through? A lengthy serious professional transition-zone where one can be involved but not in the way of the critical path of any project. Some big companies might have that, but it's just not a universal standard in this profession. Yet the work a lot of programmers/SW developers/SW engineers do is just as dangerous and critical to organizations of all kinds, as what doctors do for individuals.
    – DarenW
    Commented Oct 23, 2010 at 0:18
  • 1
    If possible i'd give an extra +1 for the tip of iceberg point!
    – DarenW
    Commented Oct 23, 2010 at 0:20

Most of the work you do is not ground-breaking

When at Uni, I worked on AI routines to control soccer-playing robots, I built compilers and hacked on operating system kernels.

But in the real world, 99%* of software development is actually pretty boring. I've always admired architects or builders who, when asked "what do you do for a living?" can point to a building or whatever and say "I did that". But most software developers can't do that. When asked "what do you do for a living?" the closest to that that I've ever been able to come is when I used to work for a company which built software that processed SMS messages for radio stations and the like... I could say, "you know when you text in to a radio station to vote for a song, well I wrote the software that processes those votes and stuff." Still no where near as cool as being able to point to a building and saying "I built that."

Of course, there are people who can say "I worked on Windows" or whatever, but I'm sure they don't actually tell anybody that for fear of the very next question being "I can't get my printer to work, can you fix that for me?"

* and 62% of all statistics are made up on the spot

  • 1
    this is true, but not ground breaking doesn't mean that it's not crucial or important. There are many applications that are not ground-breaking that without support and fixes, might crash say our economy (on the extreme side ...) ... plus there will always be innovations depending on the project from time to time ...
    – aggietech
    Commented Oct 18, 2010 at 21:33
  • 3
    Many of us break new ground every day. It may not be the cure for cancer, but we celebrate the small triumphs with high-fives all round, a round of cakes/muffins/doughnuts, etc, to mark the moment. Many jobs, not only programming, do not have an output you can show to your friends/family, but that's a matter of framing: you could say "I configure network switches, DNS servers and Firewalls", or you could re-phrase this as "You know the internet - Facebook, YouTube, Twitter and all that? Well, I help make it work". Commented Oct 18, 2010 at 22:40
  • 1
    @JBRWilkinson: +1. The best case of "re-framing" I've had was with a previous job where I worked on NurseCall hospital beeper software. You could say something generic about that like "I wrote programs that run beepers". OTOH, you can also say "I wrote software that helped hospitals runs better and I probably saved lives!!". Hadn't thought of that until now...but statistically it's probably true. I actually feel much better about that job now. ie That software got out into production earlier thanks to my effort, etc. Might really have saved lives. :) Commented Nov 14, 2010 at 8:38
  • 1
    @Guzica: That you can be/contribute to saving lives on a daily basis is probably the best job satisfaction anyone can have - well done! Commented Nov 15, 2010 at 23:59
  • 1
    Haha, excellent answer and +1 for having a sense of humour! Commented Jun 24, 2011 at 19:46

If you look at software today, through the lens of the history of engineering, it’s certainly engineering of a sort—but it’s the kind of engineering that people without the concept of the arch did. Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -Alan Kay, 2004

the full interview: http://queue.acm.org/detail.cfm?id=1039523

I'm no industry vet; Quite the opposite, I'm a recent graduate but from a top CS school in the U.S. But my instinctual feeling is that the way we are building software is wrong. Rather than hitting the pause button and reexamining the fundamentals of how we program we have just rushed forward using out dated models from the 50s,60s continually adding a little sugar on top. If we keep on like this we will never get past where we are at. Humans just can't manage the complexity of things that are the size of the MS Windows codebase. We need a new way. I don't know what that is.

I think this is the underlying reason for the feeling that big and small software shops seem to make software by hacking it together without any deep understanding of fundamental principles.

  • As a relatively recent grad, I'm under the impression that the way that a lot of places do software is wrong, but that my current place of employment is... not perfect, but they try, and it works out a lot better. Certainly there do seem to be quite a lot of places which take a horrible "brute force" approach... but if you're in one of those places, do consider looking for somewhere else.
    – user2348
    Commented Oct 18, 2010 at 19:44
  • 1
    Software development as a whole is an evolutionary process, not revolutionary. Sure, you could build a pyramid structure out of carbon nanotubes in theory that is stronger, more durable, and more lightweight than the Egyptian pyramids in theory. But it's neither practical or feasible to do so. If the place you're working is really bad, find a new job. Otherwise, don't get too caught up in perfection because real programming jobs have real constraints (like time/funding). Remember that "In theory, theory and practice are the same. In practice they're not." Commented Nov 19, 2010 at 20:11
  • >>> We need a new way. I don't know what that is. - Neither does anyone else, thus it continues! Commented Dec 26, 2011 at 18:48

I didn't get a degree, but I picked up a bit at college and university libraries and labs.

  • Big Iron - The technologies they were teaching were primarily mainframes and minicomputers. The dean of one college told me I wouldn't be able to get a job because I didn't even know what a masterfile was. I had no intention of working on mainframes since I couldn't afford one, but I wasn't going to be so foolish as to not be slightly prepared. VAXen were cool, and I was looking forward to getting paid to code on my own Micro VAX in my cubicle. What a shame that market totally imploded. (As it turned out I had two positions working with mainframes…as a contractor for IBM.)

  • Software Engineering - On the heels of Structured Programming, SASD, and other design methodologies, you might have thought we were going to be real engineers. I did. But teachers were giving very little guidance on the design techniques I read in the library. Students were left to fend for themselves and micros made it too easy to flail in code until they get an answer they were happy with. I didn't realize how much worse it was in the job market. Somehow I got to do quite a bit of new code, so it wasn't so boring. But I also took over a lot, and they were bad enough it was like a new project because I had to fix up a lot of code. It was a combination of researching existing functionality and creating new code (its replacement); writing tools to simplify the process and instituting better project management.

  • High-tech Career - It's one thing when schools have old buildings and equipment (the punch card equipment was replaced the semester before I started…in 1984), but when you're working in a poorly lit warehouse or for a boss who hangs up on customers calling the support line, you start to realize your job description isn't likely to include cooking popcorn with a 5-megawatt laser.

  • Development is mainly teamwork. That means that communication (spoken and read), reading other's code and reusing previous modules (both in-house and external) is something to face almost everyday. In my college, at least I had to code with more people in very few occasions, so I thought that the main part of the work was to code alone, in the wilderness. It is not.
  • Explaining things to non-developers is hard (also covered for the first point), and is your responsibility to make your points (not of the other 99% of the world).
  • The good test is the test that fails. (the first time, at least) And, of course, there is no such thing as a bug-free code. You're not a bad programmer if you have bugs. Bugs are just a (very important and time-consuming) part of your job.
  • There are no silver bullets. Each technology has it's advantages and disadvantages.
  • College doesn't teach you state-of-the-art technologies. But also, 90% of the works uses pretty old technologies. Which, by the way, sometimes is what is needed.
  • Non-technical people make decisions about technical solutions, mostly for esoteric reasons like maintenance, partnership, worker's availability...
  • You're just beginning, young padawan.

I've begun to realize since then about the fact that coding is a work you do in conjunction with more people, specially now that open-source is more prominent. But when I was at college (late nineties), I was convinced that I was going to be doing things from scratch and not ever looking into other's code or having to coordinate with others...

Looking back, to me one of the best parts is learning and teaching others.

  • "College doesn't teach you state-of-the-art technologies.": Yes and no. In some fields academia is 20-30 years ahead wrt the industry, and you get to learn some of that in college.
    – Giorgio
    Commented Apr 1, 2017 at 16:45
  • Computer programming is non-physical and non-intuitive.
    • When a house builder finishes his/her work, s/he can walk around and immediately see/feel if there is anything wrong. A computer programming bug cannot be discovered in the same way, and may lurk in the system for months, or even decades.
    • While a programmer may look/feel a piece of source code through code review, it is not guaranteed to spot every error contained in the code. A computer, however, would be able to exactly reproduce the error every time by executing the program with certain input. Thus, human understanding of a piece of source code is always an imperfect model of the essense of it being the instructions to a computer.
  • It is very easy to code a program that handles the most common cases, but completely fails to handle the edge cases.
    • In other disciplines, it is relatively easy to apply a remedial action after-the-fact. There may even be a body-of-knowledge specifically devoted to remedial actions. There is no such thing in Software Development.
    • Fortunately, test-driven development helps codify the edge cases that the code is supposed to handle.
    • Added On the other hand, certain software development methodologies seem to suggest that we can extract business value (faster time to market, etc.) by consciously choosing not to handle edge cases, and to communicate those decisions to the customers.
  • Customers may find business values in a software that handles only the most common cases, therefore software providers are not too concerned about handling the rare cases.
    • Customers simply learn to avoid the rough edges.


  • The elegance of the source code is not valued.
    • Customers do not see the elegance of the source code. They only see the elegance of the user interface and interactions.
    • Programmers, on the other hand, usually do not value the elegance of the user interface, and they usually do not remain in a single project for a long enough time to start appreciating an elegant software design.
    • Because neither customers nor programmers value the elegance of the source code, neither will it be valued by businesses.


My two cents: just get used to it.

  • 8
    house building compared to fixing bugs, hmm? "Hey, I just turned my doornob in the wrong direction, and the house just vanished!"
    – xor_eq
    Commented Oct 18, 2010 at 13:37

Images of ISO processes, reams of technical documentation, every feature and bug being strictly documented, and a generally professional environment describes my company fairly well. We do critical infrastructure software/hardware products though, so, well, the pressure is on for quality (we are ISO 9001 certified, for example).

  • 1
    @Guzica: One of the companies I worked for was fairly engineering-oriented. Not ISO9001 certified, but following quite stringent in-house processes pretty formally. The others were, well, as said - no more organised than a group of CS students doing a final year project together. Commented Oct 18, 2010 at 21:06

I thought after graduating that the people in charge would be able to recognize good work from bad work. After being handed the millionth copy of "really great code our top coder put together" and having it look like this:

def lf(p, q, r):
    x = 4
    xx = 4.5
    t = {1:p, 2:p+2, 3:p*4} #I think there's a bug in here but I don't know

I've almost given up trying to understand what goes on between the ears of the pointy-haired boss. "Great" means maintainence nightmare, "good" means crashes in a gentle breeze, and "horrible mess" means either that or a well structured code base whose engineers have patently refused to meet obscene deadlines just to keep their sanity.


I have heard it argued that all software engineering after the first line of code is maintainance. And that certainly seems to match my experience. The only code I have written that did not end up having most of its cost being maintaince was code that was so unsuccesful that it was never or only briefly used.

I think you can find disiplined engineering teams that develop and follow strong processes that lead to the release of robust code which the team can have a high level of confidence in (although I wouldn't convolute that with large amounts of documentation). I believe that I work in a team like that at the moment. Although I have certainly experienced the other kind of development.

The thing that I have come to appreciate though, is that the challenge is not always finding the perfect algorithm or the cleanest solution to the problem. But often trading off all sorts of constraints (resources, knowledge, money, time, skills, risk, pre-existing user training etc, etc) to achive the highest return for the available investment. That is building a system that is best suited to all those factors and not just the technical influences.

  • Very good points. Two of the medium/large enterprises I've worked in have shown a stark contrast between these two cases. One was strongly engineering oriented, and the other works more like a bunch of CompSci student teams doing separate final year projects in their own bubbles - then somehow having to integrate the stuff later. (Note: Management actually supports these "bubbles" - actual name - thinking that it's more efficient for teams to work separately than to worry about integration during development. I'm not joking.) Commented Oct 18, 2010 at 19:56

A lot of software just doesn't make it to the point where it gets used/purchased enough. When one makes it, it tends to stick around and is only "messed" with in maintenance.

User expectations are increasing every day for features, but in many areas, they are lower in areas of engineering. Let's assume banking transaction software is as solid and professionally engineered as a modern automobile. The handling of volume is a modern marvel, but what abouut the reliability of each transaction? Not so much. Your post about your puppy's first crap on the rug was dropped, so what. It's more like the little plastic bags at the grocery store. They make billions of them, they rip and tear and get thrown away. Most people don't care enough to demand a better bag.

I think quality software gets made, eventually. Some of that hits the market sooner than most comemercial products. Who gets to drive a car in Beta?

Not the answer you're looking for? Browse other questions tagged or ask your own question.