Joel Liu's List: Unserstanding developers

• This point is based on the notion that if a geek feels his ability to gain knowledge is hindered he’ll try to find it somewhere else. Let them satisfy their curiosities with the task of picking up the latest technologies and applying them as they see fit. (Even if it’s just for a prototype.)
• Don’t hinder their creativity, just let them figure it out. The exception to this is probably in design. You obviously have to define your interfaces between components and have your requirements for the implementation. Let the details get figured out by whoever’s doing the dirty work. You can optimize things later if they aren’t up to par.

• Let's say that this follows the 80-20 rule. Roughly 80% of programmers don't read books, don't go to conferences, don't continue learning, don't do anything but what they covered in college. Maybe they've gotten a job in a big company where they can do the same thing over and over. The other 20% struggle with their profession: they read, try to learn things, listen to podcasts, go to user group meetings and sometimes a conference. 80% of this 20% are not very successful yet; they're still beginning, still trying. The other 20% of this 20% -- that's about 5% of the whole who are 20x more productive.
• These people are not those who can remember all the moves and have fingers that fly over the keyboard erupting system commands. In my experience those in the 5% must struggle to get there, and struggle to stay there, and it's the process of continuous learning that makes the difference.
• But some ideas seem to have staying power. For example, a lot of the ideas in agile methodologies seem to be making some real impacts in productivity and quality. This is because they focus more on the issues of people working together and less on technologies.

• Usually the things that make or break a project are process and people issues. The way that you work on a day-to-day basis. Who your architects are, who your managers are, and who you are working with on the programming team. How you communicate, and most importantly how you solve process and people problems when they come up. The fastest way to get stuck is to think that it's all about the technology and to believe that you can ram your way through the other things. Those other things are the most likely ones to stop you cold.

   

  In my first jobs, I saw lots of managers making stupid decisions, and so, logically, I came to the conclusion that managers and management was stupid. It's a commonly held belief in our profession: if you're not smart enough to deal with the technology, you go into management. Over time I very slowly learned that the task of management wasn't stupid, it's just very, very hard. That's why all those stupid decisions are still being made; management is much harder than technology because it involves virtually no deterministic factors. It's all guesswork, so if you don't have good intuition you'll probably make stupid decisions. Napoleon wanted lucky generals rather than smart ones.
• A great new source of information is podcasts. Anyone can do these so many of them are bad, but there are some real gems out there, podcasts that specifically cover topics in our profession. I learn a lot from these, and they help me stay current.
• There's a book that uses studies to debunk beliefs about managing people and projects; it happens to be software-based but the thinking could be applied almost everywhere. This book is called Peopleware; it's small and fun to read and I recommend it to almost everyone. Alas, it really isn't a book of answers, it just firmly destroys many closely-held ideas about how people work in business situations that involve programming. The best thing about it is that it reminds you how easy it is to take a wrong idea and build a bad world around it. It helps you ask questions.
• So from your fresh new perspective things might look ridiculous, but remember that each decision on the way was made by someone weighing the issues and making what seemed like the best choice at the time. This viewpoint doesn't solve the problem but it can make you more compassionate about the people who are stuck there.

5 more annotations...

• The important thing is to understand the difference and know when you need to hack, and when you need to engineer. Unlike the previous examples where it was all one or all the other, most development work requires you to assume both of these roles at different times. When debugging or scaling, you’ll probably need to put on your engineer hat, while if you’re designing a new feature, rewriting, or doing a greenfield project, you’ll hack more. There can’t be a divide between the two, whether on a team or different roles for an individual. A scaling problem might require big-picture experimentation to overcome a serious limitation. While hacking a new site, you might need to iterate over a small, important area of a page in order to hit your sweet spot in the market. Do both, and know when to do which.

• If I had a dime for every time I heard a web programmer apologize for the way his/her pages looked before revealing them, I certainly wouldn’t need to work anymore.

   

  As with color picking, I think that programmers tend to avoid doing certain things not because they are inherently bad at it, but because they don’t know how to proceed. They find themselves in an uncharted and foggy territory, without a map, no sense of direction, and with a limited ability to know if they’re getting any closer to where they want to be. Also, when they talk to people that don’t share such problems and find it all too natural and obvious, it’s hard for the two to communicate in terms that make sense to a programmer.

• Don’t get me wrong: I don’t think anybody can design something truly beautiful, innovative, simple and that can resonate with a big percentage of the population. Far from it.

   

  I have a much simpler and humble goal here: give programmers some tricks and some advice in how to proceed to make their web pages look cleaner, more readable and, hopefully, more professional, elegant and original than before.

• nice tutorial for programmers - Joel Liu on 2008-10-29

• 3. Don't play any blame games. It doesn't matter who put the bug in. Again, your co-workers will be more loyal to you if you soft-pedal problems they introduce. I often apologize for bugs found, and gently argue with people that it was indeed my fault, when we both know it wasn't.