10 things I wished I had known starting out in Software

It's been a long hard road to learning these and so I figure I might as well pass it on . . .

10) Automate Everything
As a developer with looming deadlines there's a tendency to accept repetitious tasks (who has time to automate?) but these actions can suck up so much time and effort that it's almost always worth the effort especially if the tasks are repetitive across a team.

So automate EVERYTHING! Your build, your deployment, your smoke test, your unit tests, your regression tests, your monitoring etc. Learn great tools like Ant and Perl which will form the basis of many automation scripts.

9) Remember Microsoft vs. Apple - can you get rich and be right?
Do you want to be rich or right? The application with the least bugs, best usability and most features usually isn't the one that wins. It should - but this isn't about "should" it's about hard-learned lessons in the real world.

Sales and marketing have much more to do with success than how cool your technology is. Apple has the great design, great usability and lots of the "right stuff" but Microsoft has made more millionaires than Apple (although Apple's stock has risen a lot lately and MSFT has flatlined see here).

8) Your user's world is much bigger than your application
Your application or piece of software means all the world to you - but to your users it's just a tool. Let your user do what they need to and other than that stay out of the way. They don't care if you use Ajax and JSON or DWR, they don't mind that SOAP sucks/rules and REST rules/sucks - they just need to update some data and get back to the other million things they do every day.

7) Don't make your users think!
In the same vein as #8 - go easy on your users in terms of usability. Some web sites are so easy and intuitive to use you don't really realize it. When you notice the usability of a site it's more often than not bad news (unless it's in comparison to something worse). Learn about usability - use paradigms that users are likely to know already e.g. Windows explorer (for hierarchies of data), Microsoft Excel (for grids) etc.

Check out this great snippet from David Platt or this link! Your tool is a means to an end not the end itself!

6) Skill in Communication is the key to career advancement
The most successful developers are the one's who can communicate well - in the written form as well as in the meeting room. How can management know what is happening if you can't communicate it to them? And if you can communicate and do it really well, would you like a secretary with that corner office?

5) Developers are the worst testers
We think super-rationally and in a very linear fashion - that's the way we need to be to help write code for our dumb computers - users are just everyday people - irrational, forgetful and they think in different "nonlinear" ways - in other words, they are the normal ones - we're the weirdos! :-)

The best testers of all are those people who know NOTHING about your application or what it is supposed to do - you'll be amazed at what they'll try to do, where they'll click and what they ignore!

4) User involvement is the biggest single factor in product success
What do your users want? It's not what *you* want! Watch, listen and learn from them.

3) In the end it's ALL about Sales and Marketing
MBAs study sales and marketing for a good reason - these two activities drive revenue almost without regard to the quality of your product. Crazy eh? Why do people still buy BMWs when Toyota's are a much cheaper and more reliable? The BMW brand, the appeal to the ego, keeping up with the Jones's etc.

Why must your application be Ajax, Web 2.0 and SOA compliant? Because that's what CIOs want - perhaps not what they need, but they want it because ComputerWorld says they should or their CEO heard about it on CNN! It promises to be the next silver bullet (like EJB was, like .Net was, like the Web was etc.) so we need it now!

Can you do it? Doesn't matter, most of the time they can't tell. That's how most Consulting firms make their money - they sell the deal and the peons have to figure out how to make it work. By the time they realize, you've got their money and are on to the next job. This isn't something to be proud of but it's the way the world works. But the point - it's all about Sales and Marketing.

And for you the developer, you need to be able to sell and market yourself - What do you know? What can you do? What problems did you help solve? How flexible can you be to new demands? Get the word out on that and you'll be in good shape - you don't need to be a shameless self-promoter but you can't expect people to be psychic. Offer help, ask for help, learn from others - in the interaction alone people will learn what you're about.

2) Business operates fine on the 80/20 rule (a.k.a. the Pareto Principle)
So many developers are Type-A personalities who must get an "A+" at all times, but business doesn't operate like school - you don't need to get 90% of your application correct. There's no one single exam - it's an every day thing. You can't cram at the end either. You can get the majority of the benefit of effort from focusing on a select few of the most commonly used parts of your application.

Another instance of this is that the majority of users will be affected by a minority of bugs you find in QA etc.

The hard part is identifying the right 20% to address.

Also if you shoot for being 100% bug free your competition will eat you alive as they'll be first to market - yes with bugs and perhaps poor usability but with regular releases they can release patches/fixes and upgrades. People's expectations are sadly still pretty low for software! You don't have to be the one to change it - just be receptive to feedback, accommodate reasonable requests and they'll love you for that alone.

1) Perception is reality
This probably subsumes points #2, #3 and #4 above - again your "grade" isn't driven by some rational multiple-choice, right or wrong solution. You can deliver a not-so-great application but if you have strong relationships with your users and those controlling the purse strings you'll be in a better position than a "perfect" application but no relationship.