How have your coding values changed since graduating?

Question

We all walked out of school with the stars in our eyes and little experience in "real-world" programming. How have your opinions on programming as a craft changed since you've gained more experience away from academia?

I've become more and more about design a la McConnell : wide use of encapsulation, quality code that gives you warm fuzzy feelings when you read it, maintainability over execution performance, etc..., whereas many of my co-workers have followed a different path of fewer middlemen layers getting in the way, code that is right out in the open and easier to locate, even if harder to read, and performance-centric designs.

What have you learned about the craft of software design which has changed the way you approach coding since leaving the academic world?

Answer 1

The DRY (Don't Repeat Yourself) principal has become a lot more important to me. My criteria for successful software has changed too--I'm happiest with software that other people can extend easily.

Answer 2

I graduated from software engineering. I learned that almost nobody wants engineered software. It's expensive, and slow to develop. Many people want the complete opposite. Something that's thrown together as quickly and sloppily as possible, as long as it works. Nobody cares what the code looks like underneath, as long as it's functional. Personally, I try to push for a more professional software development practices, but realize that sometimes quick and dirty really is better.

Answer 3

The more simple the code/concept, the better. (Not overarchitecting.)

Answer 4

I graduated 10 years ago so maybe the fact that intellisense allows for more verbosity and that the delcaritiveness of HTML and XAML conveys developer intent has played a part in this, but my opinion on inline code commenting has changed considerably. While in school they taught and convinced me that nearly every line of code needed a comment. My old school mentors believed the same thing. Now I believe that I should strive to make code that clearly expresses my intent. I only comment when I can't write code that has clear intent.

Answer 5

I didn't learn much, except to not use magic numbers :/

Answer 6

I've learned that the practice which is shun upon in my school, a.k.a copy paste other people code is actually how it's done in the real world. So instead of getting failling marks for plagiarising other people's code at school, it's the smarter thing to do in the real world, leveraging on other people's well tested code/using frameworks/apis instead of trying to reinvent the wheel myself each time.

Of course i always check the code license before i use them in my app :)

Answer 7

/********************************************************
* Star encrusted header's have gone the way of the dodo *
********************************************************/

Comments are now applied if and only if necessary. Code usually is comment enough.

Answer 8

I was very lucky to work at a major company while I was in college, so I already came to my advanced development courses with sufficient disillusionment.

I would say that the main difference from school is in the nature of collaboration and distributed work. In school projects everyone (if they're in your team) has the same stake in the final outcome. In the real world, you may not know well the people that you're working with, and because of politics everyone has a different set of priorities and outcomes from the same project. For example, it may be politically beneficial to get a lot of immediate results on visible parts of the project, rather than on ensuring a safe long-term infrastructure.

Answer 9

Before college: the trick is to be smart enough to figure out the right way to create your program before you start coding. I was never smart enough, and realized my errors after 15 minutes of coding. :-(

After college: estimating time to create software is impossible to do with any accuracy, so there should be no schedules.

After a few years in industry: After consistently failing to get things right the first time, I decided it was impossible. Since I was working on the Visual C++ Debugger, I decided that the key to being a successful programmer is to be really good at debugging. You write whatever you can, then use the debugger to find the problems, then fix them.

After another few years: I switched from the Visual C++ Debugger to the Visual C# Editor. I decided that the debugger doesn't matter, the key to being a great developer is to be great at editing. I also read Fowler's Refactoring. Instead of trying to get it right the first time, or get it wrong the first time and live with it, I decided that to get it wrong the first time, and then improve the design with refactoring.

Further learnings: Simplicity and clarity of code are critical. Get those right, and you every other thing you could want (correctness, performance, ability to add new features) become accessible. Also, whenever you have a bug, don't just fix the bug, don't just fix similar bugs in other places, but change how you do things to guarantee that kind of mistake will never happen again.

As a manager, I led a team according to the values of simplicity, refactoring, clarity, testability, getting feedback quickly, striving for good design, coding practices that eliminate entire classes of mistakes, etc. We were fantastically successful. As an individual developer I continued to follow what I had learned as a manager, and had the greatest productivity of my career (although my former team was much better at it than I was.) My point is that these principles have been tested in the real world.

Answer 10

I've ended up solidly in McConnell's camp after slowly discarding a bunch of garbage I learned in school.

His book has more on good software engineering than I learned in college.

Answer 11

The things they never teach you in college:

• Schedules matter: you don't just get a deadline handed down for which you have to make the old college try.
• Every change introduces risk: Large systems usually have enough moving parts that you can't immediately understand the full magnitude of any change.
• Everything's relative: "this must be done" is really meaningless. Everything, everything, must be done. Take a number and get in line.

Answer 12

Since leaving University/College I have slowly come to the realisation that the use of inheritence and classic object oriented deisgn is not the answer to all design problems.

While I still attempt to write loosely couple and highly cohesive classes that have clear responsibilities, I find I almost never need deep inheritence hierarchies and in fact often get by without inheritence at all.

Also, I used to think code needed to be written in such a way that it is best for the compiler/computer to understand. Now I write code for other people to understand. Maybe this should have been taught in my Computer Science degree, but it wasn't.

Answer 13

I've learned a lot of things mentioned elsewhere on this thread, but the thing I don't see mentioned yet is maintainability. When writing code in college you know you'll never use it again. It just needs to get the job done. When writing code in the "real world", it will live on forever. Tools I wrote when I first came to this job over 10 years ago are still being used. Keeping code simple, straightforward, and well commented is very important.

Answer 14

Need is relative. Often what users really need is tools suited to their level of sophistication. In many cases this means a pencil.

Answer 15

The 'sacred cow' mentality has gone. Now I question everything and listen more to my instincts and common sense rather than blindly adopting and following what everyone else is doing.

Answer 16

-Simplicity and readability above all else, then work your way through there. Performance come afterwards

-Don't reinvent the wheel, but try to understand it as deeply as possible. This applies the most to the most moden frameworks available that do lots of internal magic.

-Use as much abstraction as you need and no more. It's easy to go overboard engineering for engineering's sake (look at many of the Apache enterprise frameworks for Java as an example), but there's a sweet spot where you use just encapsulation and abstraction to get the point across while having sufficiently descritive code.

-Code is for humans. Dijkstra's say about it is deep knowledge.

-There's a tool for anything and no tool does everything. Language and IDE fanboyism is especially negative. Use what you need to get the job done.