Graduate expectations versus reality [closed]

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

• 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.

Answer 6

• 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.

Added

• 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.

Added

My two cents: just get used to it.

Answer 7

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).

Answer 8

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.

Answer 9

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.

Answer 10

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?