Top ten things ten years of professional software development has taught me

· Object orientation is much harder than you think

Maybe it’s just me, but coming from Computer Science class I thought that OO was easy. I mean, how hard can it be to create classes that mimic the real world? It turns out that it’s pretty hard. Ten years later, I’m still learning how to model properly. I wish I spent more time reading up on OO and design patterns. Good modeling skills are worth a lot to every development team.

· The difficult part of software development is communication

And that’s communication with persons, not socket programming. Now and then you do run into a tricky technical problem, but it’s not at all that common. Much more common is misunderstandings between you and the project manager, between you and the customer and finally between you and the other developers. Work on your soft skills.

· Learn to say no
When I started working, I was very eager to please. This meant that I had a hard time saying no to things people asked of me. I worked a lot of overtime, and still didn’t finish everything that was asked of me. The result was disappointment from their side, and almost burning out on my part. If you never say no, your yes is worth very little. Commit to what you can handle, and if people keep asking you for more, make it very explicit that this would mean not doing something else. What I did was to have a list of stuff that I needed to do on a piece of paper with me. When someone asked for something, I showed them the list and asked what I should bump to have time to help them. This allowed me to say no in a nice way.

· If everything is equally important, then nothing is important

The business likes to say that all the features are as crucial. They are not. Push back and make them commit. It’s easier if you don’t force them to pick what to do and what not to do. Instead, let them choose what you should do this week. This will let you produce the stuff that brings value first. If all else goes haywire, at least you’ve done that.

· Don’t over-think a problem
I can spend whole days designing things in front of the white board. That doesn’t mean it will be any better, it just means it will be more complicated. I don’t mean to say you shouldn’t design at all, just that the implementation will quickly show me stuff I didn’t think of anyway, so why try to make it perfect? Like Dave Farley says: “The devil is in the details, but exorcism is in implementation, not theory.”

· Dive really deep into something, but don’t get hung up
Chris and I spent a lot of time getting into the real deep parts of SQL Server. It was great fun and I learned a lot from it, but after some time I realized that knowing that much didn’t really help me solve the business’ problems. An example: I know that at the table level, SQL Server will not take an IU lock – it will only take a IX lock. This is a performance tweak, since most of the time, the IU lock will have to be escalated into a IX lock anyway. To find this, I spent countless days experimenting, I read loads of material and talked to Microsoft people at conferences. Have I ever had any use of this knowledge. Nope.

· Learn about the other parts of the software development machine

It’s really important to be a great developer. But to be a great part of the system that produces software, you need to understand what the rest of the system does. How do the QA people work? What does the project manager do? What drives the business analyst? This knowledge will help you connect with the rest of the people, and will grease interactions with them. Ask the people around you for help in learning more. What books are good? Most people will be flattered that you care, and willingly help you out. A little time on this goes a really long way.

· Your colleagues are your best teachers
A year after I started on my first job, we merged with another company. Suddenly I had a lot of much more talented and experienced people around me. I remember distinctly how this made me feel inferior and stupid. I studied hard, reading book after book but I still didn’t catch up. They had too much of an advantage on me, I figured.Nowadays, working with great people doesn’t make me feel bad at all. I just feel I have the chance of a lifetime to learn. I ask questions and I try really hard to understand how my colleagues come to the conclusions they do. This is why I joined ThoughtWorks. See your peers as an asset, not competition.

· It all comes down to working software

No matter how cool your algorithms are, no matter how brilliant your database schema is, no matter how fabulous your whatever is, if it doesn’t scratch the clients’ itch, it’s not worth anything. Focus on delivering working software, and at the same time prepare to continue delivering software using that code base and you’re on the right path.

· Some people are assholes

Most of the time, most of the people around you are great. You learn from them, and they learn from you. Accomplishing something together is a good feeling. Unfortunately, you will probably run into the exceptions. People that because of something or other are plain old mean. Demeaning bosses. Lying colleagues. Stupid, ignorant customers. Don’t take this too hard. Try to work around them and do what you can to minimize the pain and effort they cause, but don’t blame yourself. As long as you stay honest and do your best, you’ve done your part.
Ref: http://www.taylor.se/reddit.html

10 Developers For The Price Of One

In the The Mythical Man-Month, Fred Brooks highlights an eye opening disparity in productivity between good and poor programmers (emphasis mine).

Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erickson, and Grant were measuring performance of a group of experienced programmers. Within just this group the ratios between the best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements!

Robert Glass cites research that puts this disparity even higher in his bookFacts and Fallacies of Software Engineering.

The best programmers are up to 28 times better than the worst programmers, according to “individual differences” research. Given that their pay is never commensurate, they are the biggest bargains in the software field.

In other words, the best developers are generally underpaid and the worst developers overpaid.

But don’t leave your job just yet. This is not to say that there should be a 1 to 1 correlation between productivity and pay. People should be paid by the value they bring and productivity is only part of the value proposition, albeit a big part of it. Even so, we’d expect to see some amount of correlation in pay with such a drastic productivity difference. But in general, we don’t. Why is that?

It’s because most managers don’t believe this productivity disparity despite repeated verification by multiple studies. Why should they let facts get in the way of their beliefs? That would only mean the factonistas have won.

Kidding aside, why is this productivity difference so hard to believe? Allow me to put words in the mouth of a straw-man manager.

Well how in the world can one developer write code 28 times faster than another developer?

This sort of thinking represents a common fallacy when it comes to measuring developer productivity. Productivity is not about the lines of code. A huge steaming pile of code that doesn’t get the job done is not productive. There are many aspects to developer productivity, but they all fall under one main principle (borrowing a term from the finance industry), TCO.

TCO - Total Cost Of Ownership.

In general, I’ve tried to always hire the best developers I can find. But I’ve made mistakes before. Yes, even me.

One situation that comes to mind was with a developer I had hired (under a lot of pressure to staff up I might add) at a former company. I handed off a project to this erstwhile coworker to take over. A few days go by and I don’t hear anything from the guy, so I assume things are humming along nicely.

Fast forward another few days and I swing by to see how it’s going and the developer tells me he doesn’t understand a few requirements and has been spinning his wheels trying to figure it out this whole time.

Good Developers take Ownership so You Don’t Have To

This is one of the first ways that good developers are more productive than average developers. They take ownership of a project. Rather than spend a week spinning wheels because they don’t understand a requirement, a good developer will go and grab the decision maker and squeeze out some clarity.

Likewise, a good developer doesn’t require you to prod them every few moments to make sure they are progressing. If they get overly stuck on a problem, they’ll come to you or their coworkers and resolve the problem.

A developer who can write code fast, but doesn’t take ownership of their projects is not very productive because they end up wasting your time.

Good Developers Write Code With Less Bugs

I once worked with a developer who was praised by my boss for being extremely fast at writing code. He sure was fast! He was also fast at introducing bugs into code. His code was sloppy and hard to understand.

The key measure that wasn’t figured into his productivity measurement was the amount of productivity lost by the QA team attempting to reproduce bugs introduced by his code, along with the time spent fixing those bugs by this developer or other developers.

Everyone focused on his time to "completion", but not on the total cost of ownership of that code. Code is not complete when a developer says it is complete. That is not the time to stop the stopwatch. It’s when QA has had its say that you can put the stopwatch away for the moment.

As I like to say, productivity is not about speed. It’s about velocity. You can be fast, but if you’re going in the wrong direction, you’re not helping anyone.

Good Developers Write Maintainable Code

Hand in hand with writing less bugs is writing understandable maintainable code. As soon as a line of code is laid on the screen, you’re in maintenance mode on that piece of code.

Code that is brittle and difficult to change wastes hours and hours of developer cycles when trying to amend a system with updates and new features. By writing maintainable code, a good developer can make these changes more quickly and also improves the productivity of his or her team members who later have to work on such code.

Good Developers Do More With Less Code

Another hallmark of a good developer is that they know when not to write code. As a friend always tells me

Why build what you can buy? Why buy what you can borrow? Why borrow what you can steal?

With a few exceptions, the NIH (Not Invented Here) syndrome is a pathological productivity killer. I’ve seen developers start out to write their own form validation framework until I point out that there is already one built in to ASP.NET that does the job (It’s not perfect, but it’s better than the one I saw being written).

All of that time spent reinventing the wheel is wasted because someone else has already written that code for you. And in many cases, did a better job as it was their only focus. In such a situation, finding an existing library that gets the job done can provide a huge productivity boost.

The caveat in this case is to be careful to avoid non-extensible and rigid 3rd party libraries, especially for very specialized requirements. You might a lot of time trying to fit a round peg in a square box.

Even when you must invent here, good developers tend to write less (but still readable) code that does more. For example, rather than build a state machine to parse out text from a big string, a good developer might use a regular expression (ok, some will say that a regex is not readable. Still more readable than hundreds of lines of text parsing code).

Back to TCO

Each of these characteristics I’ve listed keeps the total cost of ownership of a good developer low. Please don’t let the term ownership distract you. What I mean here is the cost to the company for having such a developer on the payroll.

By writing less code that does more, and by writing maintainable code that has fewer bugs, a good developer takes pressure off of the QA staff, coworkers, and management, increasing productivity for everyone around. This is why numbers such as 28 times productivity are possible and might even seem low when you look at the big picture.

Hopefully seeing this perspective will convince managers that good developers really are as productive as the studies show. Negotiating a 28x pay increase on the other hand, is an exercise left to the reader.

The Psychology of Computer Programming

1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.
3. No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.
4. Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
5. Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.
6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
7. The only true authority stems from knowledge, not from position.Knowledge engenders authority, and authority engenders respect—so if you want respect in an egoless environment, cultivate knowledge.
8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don’t take revenge or say, “I told you so” more than a few times at most, and don’t make your dearly departed idea a martyr or rallying cry.
9. Don’t be “the guy in the room.” Don’t be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
10. Critique code instead of people—be kind to the coder, not to the code.As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

The human principles of software are truly timeless; The Psychology of Computer Programming was written way back in 1971

Anyway

• People are often unreasonable, illogical, and self-centered … forgive them anyway.
• If you are kind, people may accuse you of selfish, ulterior motives… be kind anyway.
• If you are successful, you will win some false friends and some true enemies… succeed anyway.
• If you are honest and sincere people may cheat you… be honest and sincere anyway.
• What you spend years building, someone could destroy overnight… build anyway.
• If you find serenity and happiness, some may be jealous… be happy anyway.
• The good you do today, people will often forget tomorrow… do good anyway.
• Give the world the best you have, and it will never be enough… give the world the best you’ve got anyway.
• it is between you and God…It was never between you and them anyway.

How to Motivate & Achieve Goals

If you can stick with a goal for long enough, you’ll almost always get there eventually. It just takes patience, and motivation.

So motivation, in its best form, is a way for you to want to do something. There may be times, for example, when you don’t feel like getting up early, and in those times you may seriously just want to sleep in

(not that there’s anything wrong with that). But if you have a reason to want to get up early, something you really really want to do, you’ll jump up out of bed with excitement.

Ways to Motivate Yourself From the Beginning

Start small.

Don’t start out big! Start out with a ridiculously easy goal, and then grow from there. If you want to exercise, for example, you may be thinking that you have to do these intense workouts 5 days a week. No

— instead, do small, tiny, baby steps. Just do 2 minutes of exercise. I know, that sounds wimpy. But it works. Commit to 2 minutes of exercise for one week. You may want to do more, but just stick to 2 minutes. It’s so easy, you can’t fail. Do it at the same time, every day. Just some crunches, 2 pushups, and some jogging in place. Once you’ve done 2 minutes a day for a week, increase it to 5, and stick with that for a week. In a month, you’ll be doing 15-20. Want to wake up early? Don’t think about waking at 5 a.m. Instead, think about waking 10 minutes earlier for a week. That’s all. Once you’ve done that, wake 10 minutes earlier than that. Baby steps.

One goal.

Too many people start with too many goals at once, and try to do too much. And it saps energy and motivation. You cannot maintain energy and focus (the two most important things in accomplishing a goal) if you are trying to do two or more goals at once. You have to choose one goal, for now, and focus on it completely. You can always do your other goals when you’ve accomplished your One Goal ( or that one goal becomes you habit).

Really,really want it.

it’s not enough to think it would be cool to achieve something. It has to be something you’re passionate about, something you’re super excited about, something you want deeply. Make sure that your goal meets these criteria, or you won’t stick with it for long.

Build anticipation.

If you find inspiration and want to do a goal, don’t start right away. Many of us will get excited and want to start today. That’s a mistake. Set a date in the future — a week or two, or even a month — and make that your Start Date. Mark it on the calendar.

Get excited about that date. Make it the most important date in your life. In the meantime, start writing out a plan. And do some of the steps below. Because by delaying your start, you are building anticipation, and increasing your focus and energy for your goal.

Ways to Sustain Motivation

Just start.

There are some days when you don’t feel like heading out the door for a run. Well, instead of thinking about how hard it is, and how long it will take, tell yourself that you just have to start. I have a rule that I just have to put on my running shoes and close the door behind me. After that, it all flows naturally. It’s when you’re sitting in your house, thinking about running and feeling tired, that it seems hard. Once you start, it is never as hard as you thought it would be.

Read about it.

When I lose motivation, I just read a book or blog about my goal. It inspires me and reinvigorates me. For some reason, reading helps motivate and focus you on whatever you’re reading about. So read about your goal every day, if you can, especially when you’re not feeling motivated. Inspiration, for me, comes from others who have achieved what I want to achieve, or who are currently doing it. I read other blogs, books,

magazines. I Google my goal, and read success stories.

Chart your progress.

This can be as simple as marking an X on your calendar, or creating a simple spreadsheet, or logging your goal using online software. But it can be vastly rewarding to look back on your progress and to see how far you’ve come, and it can help you to keep going

Reward yourself often.

For every little step along the way, celebrate your success, and give yourself a reward. It helps to write

down appropriate rewards for each step, so that you can look forward to those rewards. By appropriate, I mean 1) it’s proportionate to the size of the goal (don’t reward going on a 1-mile run with a luxury cruise in the Bahamas); and 2) it doesn’t ruin your goal — if you are trying to lose weight, don’t reward a day of healthy eating with a dessert binge. It’s self-defeating.

Never skip two days in a row.

So, you missed one day … now the second day is upon you and you are feeling lazy … tell yourself NO! You

will not miss two days in a row

A Life That Matters

Ready or not, some day your life will come to an end.

There will be no more sunrises, no minutes, hours or days.

All the things you collected, whether treasured or forgotten, will pass to someone else.

Your wealth, fame and temporal power will shrivel to irrelevance.

Your grudges, resentments, frustrations, and jealousies will finally disappear.

So, too, your hopes, ambitions, plans, and to-do lists will expire.

The wins and losses that once seemed so important will fade away.

It won’t matter where you came from, or on what side of the tracks you lived at the end.

So what will matter?

How will the value of your days be measured?

What will matter is not what you bought, but what you built.

What will matter is not what you got, but what you gave.

What will matter is not your success, but your significance.

What will matter is every act of integrity, compassion, courage or sacrifice that enriched, empowered or encouraged others to emulate your example.

What will matter is not your competence, but your character.

What will matter is not how many people you knew, but how many will feel a lasting loss when you’re gone.

What will matter is not your memories, but the memories that live in those who loved you.

What will matter is how long you will be remembered, by whom and for what.

Living a life that matters doesn’t happen by accident.

It’s not a matter of circumstance but of choice.

Choose to live a life that matters.

Single most important thing to improve your programming career

The single most important thing you must do to improve your programming career is improve your ability to communicate. To program, you must elicit ideas from other people and share your ideas with them. Sharing ideas comes in many forms: explaining how you did something. Suggesting a new practice for the team. Demonstrating how something works. Convincing everyone to switch programming languages. Persuading a brilliant engineer to join your team. Persuading your manager to get out of the way and let you do your thing Advancing your career is entirely about communicating. Getting a job. Turning down a job. Asking for a promotion. Turning down a promotion. Getting onto a good team. Politely extricating yourself from a good team. Persuading a brilliant engineer to co-found a company. Helping a brilliant engineer understand why co-founding a company isn’t the right thing to do. Asking for funding. Turning down funding. Getting clients. Turning down clients.