Are my negative internship experiences representative of the real world? [closed]

Question

I'm curious if my current experiences as an intern are representative of actual industry.

As background, I'm through the better part of two computing majors and a math major at a major university; I've aced every class and adored all of them, so I'd like to think that I'm not terrible at programming. I got an internship with one of the major software companies, and half way through now I've been shocked at the extraordinarily low quality of code. Comments don't exist, it's all spaghetti code, and everything that could be wrong is even worse. I've done a ton of tutoring/TAing, so I'm very used to reading bad code, but the major industry products I've been seeing trump all of that. I work 10-12 hours a day and never feel like I'm getting anywhere, because it's endless hours of trying to figure out an undocumented API or determine the behavior of some other part of the (completely undocumented) product. I've left work hating the job every day so far, and I desperately want to know if this is what is in store for the rest of my life.

Did I draw a short straw on internships (the absurdly large paychecks imply that it's not a low quality position), or is this what the real world is like?

Answer 1

They call it the Real World™ for a reason.

99% of what you will encounter in the real corporate world will be considered crap, and for good reason that I will explain. The 1% that isn't considered crap will become crap eventually.

#1 Write Code, #2 ????, #3 Profit!

First off businesses exist to turn a profit, they do not exist to generate mountains of perfectly theoretically clean designed and pristine academic code housed in golden repositories of perfectness. Not even close, not even the ones in the business of selling source code they produce.

In the business world code is a means to an end. If some code solves a business problem and makes more money than it costs to create and maintain then it is desirable for the business. Employing you to write code is just one way for the business to obtain code.

Theory 0 - Practice ∞

Ideally maintenance should be more of a concern but it usually isn't, because in the short term it doesn't win out financially. In the long term, software usually has a relatively short life cycle, especially web based applications, they get obsoleted quickly and re-written more often.

In house line of business applications are the ones that churn on as what are perceived as endless zombie projects because of many momentum based reasons. These projects are actually successes they continue because they continue making the business a profit.

In theory there is no difference between theory and practice. In practice there is. - Yogi Berra

In theory perfectly architected absolutely clean pristine code bases with 100% code coverages should save companies money, in practice it doesn't even come close to delivering any thing close to a valid return on investment.

Physics of the Software Lifecycle

There is also a super powerful entropy force at work in the world of software. It is a black hole of inevitability that condemns all software to degenerate into a Big Ball of Mud.

The farther you start from a BBM the better, but every software system will eventually get there given enough time. How quickly you approach 100% entropy is determined by where you start and how rapidly you pile on technical debt and how high the interest on it is.

Software systems degenerate and rot because of maintenance, not because of the lack of it. A system that is in place for years with no code changes by definition meets all its requirements and goals and is a success.

It is the systems that require constant change because they started out closer to maximum entropy are the ones that are constantly poked and prodded and it is the maintenance that accelerates the negative change.

Good Enough is Good Enough

Short lifecycle systems like websites that change constantly don't benefit from expensive huge upfront design 100% code coverage in unit tests, because the amortization time is too short to recoupe the costs.

Long lifecycle systems like the above mentioned internal line of business apps, don't really benefit from massive investments of 100% code coverage unit tests either, because the rate of change over the life of the project approaches a constant that is near zero in a non-linear fashion.

That is why end of life plans are more important and replacement systems should be planned just as something is being released, not when it has passed it prime by a few years and unsupportable so a new system must be rushed into place.

They don't teach about BBM as far as I know, I have never encountered a recent CS graduate that knew what it was, much less why it happens.

That is why Good Enough is Good Enough, anything more or less isn't.

Software Slumlords

There are real estate slum lords for a reason, they make a profit on the run down shanty buildings they own. The make more profit than they spend on incremental maintenance of the run down property. If they didn't they would tear down the building and replace it. But they don't, because the incremental costs are far less than overhauling or replacing the entire building. There are also customers ( tenants ) that are willing to pay for run down property.

No building owner, slum lord or not is going to spend money on a property just because of some academic notion of perfection that doesn't translate to a substantial profit over the associated cost.

No customer is going to pay for upgrades to a software system that is working acceptably to them. No business is going to spend money on just writing and re-writing code for no tangible substantial profit.

Microsoft is most dominate and successful software slumlord there is. Windows did not start getting major foundational re-writes until very recently. And they still haven't dropped all the legacy code from the kernel. It doesn't make business sense to them, people are more than willing to accept the low bar of expectations they have set over the last decade.

Prognosis

This has been a pattern for the 20+ years I have been in software development. It isn't going to change any time soon. This isn't the way people want it to be out of some belief system, it is a reality of external forces on a business. Business drives decision making, profits aren't evil they pay your salary, short term or long term vision is irrelevant, this is a short term industry of constant change by definition. Anyone that argues against good enough to make a profit doesn't understand business.

I spent 15 years consulting and learned very quickly that good enough was just that, anything else was costing me money. Yeah I wanted things to be perfect, but unless you are selling a code base, which 99.99999% of the time you are selling a solution, all that prefect clean organized elegant code is lost and you just wasted your time you will never get reimbursed for.

Progress and Hope

Agile methodologies are a good step in the right direction, at least philosophically. They address the chaos and constant change as a first class citizen and accept it. They reject dogmatic practices, acknowledging that the methodologies and practices should change as well as the requirements and technologies.

They accept the entropy that is introduced by the lack of time or changing requirements, changing staff and the liveness of a software system with the concept of technical debt.

But Agile isn't a panacea, it isn't going to change the fundamental laws of physics and code bases will rot regardless. It is up to management to plan on dealing with the rot before it gets completely out of hand and un-manageable.

Agile when done correctly, helps manage the entropy, slow it down, track it, measure it and deal with it in a planned manner. It won't stop it!

Career Decision

If this is a real philosophical problem for you, you should probably consider other career choices, because the way things work has valid business merit behind it. Open Source projects don't have any better track record, and in many cases the code is even worse than most corporate code I have seen.

Answer 2

I'm curious if my current experiences as an intern are representative of actual industry.

No it is not. It is representative of your career level and experience. It's all part of learning about how businesses work from an internal quality control perspective.

As background, I'm through the better part of two computing majors and a math major at a major university; I've aced every class and adored all of them, so I'd like to think that I'm not terrible at programming. I got an internship with one of the major software companies, and half way through now I've been shocked at the extraordinarily low quality of code.

Your skills, your experience, your education has no impact on the quality of work done by others. Simply because you don't have the authority to change those practices. It doesn't matter if you were good or bad in university. That doesn't change how the company you work for currently operates. So while it's great you have all this background. It's really for your own benefit and not theirs. That's why it's important to study what you love.

I got an internship with one of the major software companies, and half way through now I've been shocked at the extraordinarily low quality of code. Comments don't exist, it's all spaghetti code, and everything that could be wrong is even worse. I've done a ton of tutoring/TAing, so I'm very used to reading bad code, but the major industry products I've been seeing trump all of that.

What I have learned in my many years of programming is that there is a difference between "quality of code" and "acceptable code". The truth is that either someone with authority finds the source code in acceptable condition, or they find it unacceptable but necessary. While it would be nice if we could all clean up the projects we get involved in. It's often not in the businesses interest or budget to allocate resources to do that work. Logical arguments can be made until the sun rises the next day why this would be a good thing to fix, but when management has decided the current state is "acceptable" then little can be done. It is all directly related to who runs things. Either they value good internal quality or they do not. You clearly value it and therefore this current state bothers you.

You will find examples of this type of problem in any industry that depends on internal quality control. Ranging from software development to manufacturing. You need to learn to see this not as a problem, but simply as the current condition of their source code. This is how it is, it takes X number of minutes to find something, it takes X number of minutes to fix something.

The business either doesn't care about this extra time, or it finds it acceptable.

I work 10-12 hours a day and never feel like I'm getting anywhere, because it's endless hours of trying to figure out an undocumented API or determine the behavior of some other part of the (completely undocumented) product. I've left work hating the job every day so far, and I desperately want to know if this is what is in store for the rest of my life.

Why was it acceptable for you to put in long hours in university to study a subject, but now it is not acceptable to put in long hours to study source code? I'm sure the reason the employer hired you was because they thought you could handle it.

Let me give you some advise. Good developers know when to ask for help from their follow teammates. Don't think the answers are always in the code. I've saved myself hours of time by simply asking people a few questions. Sounds like you need some help coming up to speed.

Secondly, we don't know the work conditions. Working long hours is a fact of life in so many industries. That you need to resolve on your own, but I can tell you. Hating your job is never a good sign. You should deal with that feeling and get to the root of it. I'm sorry that you find this experience negative.

Did I draw a short straw on internships (the absurdly large paychecks imply that it's not a low quality position), or is this what the real world is like?

You were doing very well in school, but now you have an internship and you're not doing so well. Sounds like you're already in the real world. That's part of life. The question is, what are you going to do about it? That my friend, is the only thing that matters. We can't tell you what to do. You have to make up your own mind.

I can tell you that it sounds like your experience at your age was far better then any opportunities that I had. Life for me in the 90's was a struggle to pay rent and find my next contract. Consider yourself lucky.

Answer 3

After 25 years and a variety of companies and industries I can say:
Yes, it's pretty common.
This is why engineers are paid pretty well usually, they have to be good at encountering messy hodge-podges and still be able to make changes while resisting the pressing desire to refactor the whole damn thing and find out what the hell it's really supposed to be doing. I threw the emotion in for you there - it's normal to feel that way about the code you encounter!

The code you see will often have gone through endless iterations by different programmers with different approaches and standards and different naming conventions, etc. etc.

What happens though is that the $ pressure is always on. It's always tempting to describe how and why better code is the only way in the long-term but in a great deal of jobs the clock is ticking for a short-term quick-fix solution. It only takes 1 engineer a short time to destroy standards in a project. It takes a very good manager that knows how to prevent this and defend the right approach (when reasonably possible) to really address it.

One thing is for sure, the term 'good code' is just too subjective to be useful. It's not subjective to you of course, you can list the specific reasons / items. However other people list different items and priorities, some not even technical, that they think are important, and thus it's subjective.

Like Drekka, this is starting to sounds depressing, so let me try to turn a little more positive, because it's certainly true that:-

• There are organizations, often ones with the largest technical components that are doing the right things.
• The newer the company... and the code... the cleaner it tends to be. spaghetti grows due to time and people.
• Some folks do TDD and BDD, others don't. The range is huge.
• After about 10 years, currently, the entire technology base changes so those who stay in the industry can have as hard a time keeping up as do newbies.

Finally, as Anthony Blake points out, there are always 3 factors - time, cost and quality.
I like the related expression: "pick 2" !

Answer 4

There is lots of opinions about this because everyone's experiences are different.

Mine are that about half the developers I encounter are well intentioned, but of average ability. There is a small group of brilliant people at the top, and a small group at the bottom who are trying but basically should do something else because they don't really get it. Unfortunately there is also another small group of incompetent fools who think they are way cleverer than everyone else and are usually quite in your face about how you should be following them.

Project wise, I've gone into a lot of jobs and immediately been asked to "look after" some established project, usually one that the business has just discovered it really needs after loosing the last developer on it. I usually find exactly what you have outlined above - undocumented, over-engineered, buggy spaghetti. Sometimes I can fix it, sometimes I just start again. It doesn't even need to be old code, I've found this on new projects I've been asked to "help out" on as well.

You have to take heart from the fact that most companies are going to give interns the crappy jobs. The fun ones come after you have done two things: 1 - proven yourself and 2 - made some time to work on things other than fixing other people's mistakes. In other words you have to show ability and initiative.

The real trick to handling bad code is figuring out what is salvageable and what is not. This comes from experience and research.

The other career option you have is to stop working for established companies and look to work in startups. Then there will be no crap legacy code to maintain so you will have the chance to help build something better. The downside is that the pressure to deliver placed on startup projects often means that shortcuts and hacks are used when they should not be.

Programmers are all too often willing to take on tech debt in order to deliver early or on time. Unfortunately the impact of this tech debt is often glossed over, minimized, ignored or dismissed by the developers and management until it's too late and they are in trouble.

Sorry if this sounds depressing. I'm sure someone else can do a more positive piece. :-)

Answer 5

There are some great answers here, but let me add my bit;

Welcome to the real world - unfortunately this is very common.

Refer to the diagram below;

With corporate software, you can only pick 2 or the above, and you must sacrifice one.

As you seem to have discovered, the majority of the corporate world go with speed and price.

Answer 6

Not totally indicative of the industry, but from my limited experience 5+ years. I'd work through your internship and take as many lessons as you can from the experience. Look for hallmarks, and indicators. For example for your next position you'll without doubt have to go through a series of interviews. This process is a two way road, and gives you a chance to get a feel for a company. This is vitally important and will likely lead to your own happiness and well being.

To sum things up, spot the tell tale signs;

• Who's running the company? Is it a single manager, the marketing team (if so, stay away), development team, etc. This angle means you might get more or less leverage for projects, the time spent on projects, etc.
• Is there a technical appreciation? Look how the management, supervisor, and members of the team treat each other. I've been in an interview where the managers has been doing all kinds of eyebrow movements once the technical lead started speaking. After that and learning they didn't use source control - you couldn't show me the door fast enough.
• Business goal? Does the company live day by day, as in daily financial targets, or does it have a long term plan which you are a part of. Software development is generally done over months so having a company with a schizophrenic nature usually leads to messy software.
• Dig around heavily - when asking technical questions and see if people shuffle. Source control, document control, release process, bug reports, management style, T&C's, etc.

So live and learn, and think about your next role. Having a bad experience isn't all that bad, because you'll be better educated about the world of work & business.

Answer 7

Well, I'm running up on my second decade in the business, and I can tell you that perfect clean code very seldom happens, and when it does happen, it doesn't long stay that way. By and large you will find yourself constantly attempting to repair the mistakes of the past, while (sadly) being forced by time constraints and poor leadership to commit the mistakes of the present.

Unless you're in a very specific kind of software business, the pressure to get a functional product out the door overrides all other concerns, and optimization beyond a certain point is considered pointless. If the program runs in 5 minutes, and we only need it to run in 5 minutes, no one is going to give you a few weeks to get the runtime down to 2 minutes.

If, by some miracle, you have that perfect confluence of competent management, a clear goal, money, talent, and time, and you produce a clean, superiour product...The only way it will stay that way is if you never touch it again. Maintenance and extension is almost always given very low priority, changes are always needed on effectively zero notice, and end up being kludged in erratically.

I was thinking about this one project yesterday. It was such an obvious pipe-dream to me, that I bounced a really minimally functional piece of crap out the door. I viewed it as a waste of time and resources.

Well, surprise, surprise, everyone loved it and it worked out well. So I jumped back to the drawing board and did it right. And the new version was amazing! But then there was a turnover in management and the whole thing was scrapped in favor of a "new business direction."

The second iteration had a really half-assed deployment within the company, and I never heard another thing about it, which is amusing because I know at least ~10 business units are still using it (the software we're commissioning to do the job is almost 2 years behind schedule) and apparently it never breaks.

This brings us to my final point. Even if you do produce something miraculous, the fact that it works so well means that NO ONE will be in the least bit familiar with it, and when it breaks (usually because they did something stupid) then they will curse your name worse than they ever curse that idiot who wrote that thing that breaks every third Tuesday.

Answer 8

It's hard to tell what you consider horribly low quality code, but yeah few programmers are very good (by definition). As software evolves, people make mistakes. Over time these build up, and business pressure (and programmer laziness/ignorance) makes refactoring... Uncommon.

Answer 9

I would attempt to sum up an the answer to this questions with a simple quote:

All code turns to crap given enough time and hands.

The rest are just stories...

Answer 10

Welcome to code with a budget! There's a big difference when development is pushed by management to be done too soon, without planning, and with cutting corners. I had a similar experience of real world shock when I got my first programming job out of college. No documentation! Over time I learned a lot of the time, writing and keeping formal documentation up to date is just a waste of time. Luckily for me, that was an awesome team. It was lead by a guy who knew what he was doing and the other team members really cared about writing code the right way. Since then, my experiences have been similar to yours. Lots of horrible code, lots of bad code, lots of clueless "developers". For every good developer, there seem to be 100 bad ones.

You're not doomed to hate your job forever. You just have to find a company smart enough to recognize long term benefits that is willing to invest a little bit up front. I've managed to prove doing things the right way instead of the fastest way is beneficial and have become very respected and trusted for that at the companies I've worked at. Over time, the spaghetti code is fixed or becomes obsolete and your code takes over. Just be prepared to compromise. Sometimes the coolest or most robust way of programming something is just overkill and it's ok to do it the quick and dirty way.

Answer 11

Can't really talk for everyone but here is what I can say.

I haven't work 30+ years in the domain but I saw enough to say a few things. A project has a lifetime pretty much like a human. Initial design may not fit the current needs for let say one project after 20 years of development. That said in that amount of time, a lot of people changed the code messed with it and added things that weren't supposed to be possible at first.

It's not really difficult to imagine ugly code on legacy projects or fairly old projects. We can't expect everyone to fully understand the initial designs. It's sad but that's the way it is.

That said, you have to keep in mind that refactoring a legacy project is not always possible and sometime not even desired. I worked in a company where they were developing the replacement for the project I was working on. I wasn't allowed to refactor too much my project in fear that it would work better than the new project. I'm pretty sure there is no way this project could ever work better than a new fresh one. the phrase was a bit like "Don't make it better, just make it work".

Eventually you won't have that kind of project often, as I often read and listen. You should try to find work with startups instead of big corporation. Startups are quite interesting and you can eventually move on fast if you see that it's not going the way you want it too.

Also one thing you can do, I really don't promise anything but if you feel the code is really that bad and need refactoring. Share it with the team. Keep in mind that the people who wrote that ugly code might be working with you. It's not about hurting people's feeling but if you see that the project you're working on will collapse after sometime and people will spend more time understanding what it does instead of improving it. It's better to speak up and communicate the problem than keep it for yourself. If you're lucky enough you might end up refactoring the project.

If you end up refactoring the project, you might end up being the person pointed at for bad design choices! And then you might understand why refactoring doesn't happen that often. Hopefully if the whole team has to refactor, then nobody get pointed at. They'll just fire everyone =)

Answer 12

Code Quality depends mainly on two factors.

First is always money. Companies that have high survical pressure usually pay low wages, engage less experienced developers, have tight schedules and neither time nor money to leverage their developers.

Second is people. First of all those who decide on budgets must opt for spending in code quality, then they have to engage people who want to "live" it. As you can imagine, It might turn out hard to convert a well-paid fifty-year-old top-down-Delphi programmer (no intent of stereotyping, sorry) into an Up-to-date Java Developer who does CI Builds and produces loosely coupled code. Many developers have an aversion for lessons by (maybe younger)fellows, they don't like someone fishing in their pond - or rattling their throne.

So with that said, and also considering the fact that you have legacy code in next to every company, I'd say you get a lot of that in real life. What you could do is behave like a boyscout: Go into the woods, pick up some garbage and clean it out. Next time you'll have less of a mess to step through.

Answer 13

I got an internship with one of the major software companies

Not all companies are the same. You'll find crappy teams and crappy software code bases in most companies. But you can also find great teams and great code bases.

I think the guys at Solaris did a very good and honest description of the kind of code bases that you'll find in large companies: http://hub.opensolaris.org/bin/view/Community+Group+on/dev_solaris

I've left work hating the job every day so far, and I desperately want to know if this is what is in store for the rest of my life.

No, I've been coding for more than 15 years and I still love it.

That's not to say that everything has been perfect. I've seen some horrible code bases and also some great ones. The trick is to find the right place for you.

A large company is very different from a small one. Within the same company team A sometimes is very different form team B. Find the one that has the right balance for you (e.g. challenging projects, a culture that you enjoy, good pay, et cetera)

Good luck!

Answer 14

Your negative experience is all-too-typical of big well-known name-brand companies which a lot of developers learn to approach with a great deal more caution and trepidation than they did the first time they had an opportunity to work at one. Basically, the more layers of management you have, the more mediocrity is championed. Middle-managers don't report to upper-managers on quality of code. They report on features delivered in X amount of time and give powerpoint presentations on the neato UI feature they're hoping works just long enough to get them through it. If it all collapses in on itself a month later, that's usually somebody else's problem and they know that.

So yes, the devs that are lifers at such places tend to not care overly much. They couldn't survive there if they did. I've heard it said of Silicon Valley, that if you want to be lazy, work for one of the big names. If you want exciting work, look for a more recent startup that isn't a household name yet. I work in Chicago and can vouch for a similar phenomenon here.

As a general rule (with plenty of exceptions I'm sure), you will find a higher appreciation for quality code at companies that are smaller and managed or owned by people who also continue to write code. The compensation is often less, but the work is often much more rewarding in my opinion.

As an entry-level dev you're not likely to have a lot of control over who you work for at first but I will say that having a big name on your resume for a year or longer definitely excites recruiters and HR people. Also, you can learn quite a bit you wouldn't learn otherwise working for someone completely awful in the first six months or so and it also helps you get a better grip on which best practices actually matter and why and which ones are just tech-fads.

And of course when working with more main-stream popular corporate tools you're going to tend to find that median talent levels are going to be pretty crummy. If your primary skills are some combination of Java and C#, expand your horizons a little. You might find a happier niche at the mid-level writing Erlang or Python or :o JavaScript.

And don't let anybody tell you any different. You might not have a choice in the matter of how to proceed but crap code is !@#$ing expensive.

Answer 15

I've seen similar things as you. I have two experiences of cases when it occurs.

1. When the development is too project driven. The only thing that matters is to deliver functionality on time, then sign off. Next change will be done by someone else, by some other team/project manager with a new budget.
2. When a piece of software is maintained by just a few people over a long amount of time, developers tend to get lazy, since they know thier piece of software anyway. Academic principles are far away.

It's sad, but that's how it is at some places.

See if you can make a small change for the better, get used to it or change to another company and ask to screen some code at the interview :-)

Answer 16

This is going to be a short answer.

Education is very useful for making you feel qualified and idealistic. This is a good thing, and you should try to hold on to the idealism.

If you are at all objective, and you can look back at your own work in the future, its not going to be a very fulfilling experience. Unless you lie to yourself or you learn nothing you are going to see many ways to improve what you have done.

In general, the whole world is doing this around you. So, when you look at work from the past, exceptions aside, it will appear inferior and in need of improvment. If you don't feel like this, it means you are doing the wrong work, or its paying too well.

The good news is, you can benefit from other's mistakes and from comparison with the past. If all applications worked well and were easy to maintain new developers would not be required. In my opinion, maintaning some other developers cruft is a useful learning experience and should be an obligatory training element for all blue sky developers.

Answer 17

Your question focused on internships. I never had a programming one, but did intern at a radio station, not really applicable here.

Your question also mentioned your experiences during your internships. Your internship experiences and the answers you have received so far all pretty much sum up my experiences, after what is now twenty-seven years of writing software (started mid-June 1985).

I never quite believed it during school when our instructors said there is more thinking than actually writing code. They were right. And, if you're trying to figure out someone else's code, it is worse with no comments, and almost as bad with comments. Try sustaining a home-grown municipal tax collection system with no comments, no documentation, no formal build, and no source code control.

Whenever you can do well without its being a direct violation of standard orders, then do well. Always remember, it is easier to apologize for doing something you didn't ask permission to do than to have permission not be granted and go against a direct order.

Don't forget the standards you were taught in school. They're not useless, but more than likely those standards are the asymptotes in Calculus limits. You can always try to approach them, but you might never reach their value.

Good luck.