Feel like a geek and get yourself Ema Personal Wiki for Android and Windows

20 May 2010

Joel on software - a summary: 2010

This is a summary for the blog by Joel Spolsky, Joel on Software, volume 2007. The summary for the years 2000-2010 can be found on the Joel on Software summary index page.


It's a waste of time to involve everyone in everything. Reduce communication lines as much as possible. -- A Little Less Conversation.

A great tester gives programmers immediate feedback on what they did wrong, but also on what they did right. It's demoralizing to have only the negative feedback. -- Why testers?

To get a popular blog, it has to be about your readers and things that interest your readers, not about yourself. -- Let's Take This Offline.

~ ~ ~

17 May 2010

Joel on software - a summary: 2009

This is a summary for the blog by Joel Spolsky, Joel on Software, volume 2007. The summary for the years 2000-2010 can be found on the Joel on Software summary index page.


To software developers applying to a small company: everything about your resume has to scream getting your own hands dirty. -- Blog post 2009/01/02.

If you can't think of anything to say, maybe you should just shut up. -- Blog post 2009/01/12.

Don't be fanatic about coding principles like TDD and SOLID, which can be bureaucratic and limiting. What really matters is, how quickly you can respond to real business needs with your code. -- From podcast 38.

Success is the product of a combination of factors that came together in precisely the right way at precisely the right time. Failure is often caused by a collapse of motivation to try and turn the dials to find success. -- Start-up static

Programmers should not report to the person who writes the specs (the program manager). To be effective, the program manager should have earned respect from the programmers. -- How to be a program manager.

Treating your customers well really does pay off. -- Why Circuit City Failed, and Why B&H Thrives

You won't get rich by selling gap-filler applications, because the platform with the gap will fill the gap itself if it's urgent. -- Blog post 2009/06/10.

Duct tape programmers prefer a shippable product over politically correct code. They tend to avoid cool technologies that are all totally reasonable, but are just a little bit too hard for the human brain. -- The Duct Tape Programmer.

It appears to be a permanent part of the human condition that long term deadlines without short term milestones are rarely met. -- Capstone projects and time management

If you want passionate users, your mission should be expressable as "We help $TYPE_OF_PERSON be awesome at $THING”. -- Figuring out what your company is all about

Slow growth may result in slow death if there happens to be a competitor that grows fast. -- Does Slow Growth Equal Slow Death?

Micromanagement is needed when somehow uncaring people are involved in a project. -- When and How to Micromanage

The minimum bar for a reliable service is not that you have done a backup, but that you have done a restore. -- Let's stop talking about "backups".

11 May 2010

Joel on software - a summary: 2008

This is a summary for the blog by Joel Spolsky, Joel on Software, volume 2007. The summary for the years 2000-2010 can be found on the Joel on Software summary index page.


To attract the kids who are really interesting in programming, a programming-intensive BFA in Software Development should be created. -- Undergraduate programming.

Instead of imposing a statistically meaningless measurement of downtime, set up a program of continuous improvement. Ask "why" until you know what caused a problem and correct the root cause. -- Five whys

The Office binary formats are complex because the applications are ridiculously complex. Don't use it, let Office do the work for you (via COM automation) or use a simpler file format (like CSV or RTF). -- Why are the Microsoft Office file formats so complicated? (And some workarounds)

"Seeming impossible" is practically a requirement for a truly great innovation. Real innovation happens when someone tries anyway, overlooking an obvious flaw, and finds a way to make an idea work. -- Inspired Misfires

Employees didn't start the company and won't behave like people who did. -- Lessons I learned in the army

Consumers (= your wife) don’t give a flicking flick about your stupid religious enthusiasm for making web browsers which conform to some mythical, platonic "standard" that is not actually implemented anywhere. -- Martian headsets

A lot of good developers are working on hopeless and useless architecture astronomy because companies like Microsoft an Google are driven to grow at all cost, even though they can't think of a single useful thing to build for us. -- Architecture astronauts take over.

Don't disable options. Instead, show a message to the user why the action can't be completed. -- Blog post 2008/07/01.

Procedures need to be flexible, otherwise they can evolve into something that looks more like antagonism toward customers. -- Good System, Bad System.

The purpose of middle management is to create useful channels of communication. -- How I Learned to Love Middle Managers

If you're stuck, the "Hair on fire" strategy may help: do nothing except finish the project. -- Hair on fire.

Measuring performance and stimulating performance by commissions is tricky. Employees will figure out how to get the number you want at the expense of what you are not measuring. -- Sins of Commissions

A lot of the principles advocated by Joel Spolsky don't really matter for a project to be successful, as long as the people working on the project are smart and get things done. -- The Unproven Path.

If you are a student, to get the job you want: 1. schedule your interviews as close as possible. 2. Don't accept a forced deadline that prevents you from taking other interviews. 3. Or accept it only verbally and just cancel it if you get a better offer later. -- Exploding offer season.

Management should be an administrative function. Authority and respect are earned and not bestowed. -- My Style of Servant Leadership

Stop listening to Joel Spolsky. -- Amnesia.

05 May 2010

Joel on software - a summary: 2007

This is a summary for the blog by Joel Spolsky, Joel on Software, volume 2007. The summary for the years 2000-2010 can be found on the Joel on Software summary index page.


You can't skip the design step. And you can't design in a meeting. -- The Big Picture

To get remarkable customer service: 1. Fix the problem. It's crucial that tech support have access to the development team. 2. Don't give customers the idea they are stupid. Instead of telling them to check if the connector is plugged, tell them to unplug the connector and plug it back in. 3. Be flexible. When customers have a problem and you fix it, they’re actually going to be even more satisfied than if they never had a problem in the first place. 4. Take the blame. 5. Be polite. 6. Don't take it personal. 7. Always return the money if customers are not happy. 8. Get the good guys for customer service. Give customer service people a career path. -- Seven steps to remarkable customer service.

It takes a mindset of constant criticism to find the thousands of tiny improvements to your software that makes it a great product. -- A Game Of Inches.

When you ask people to choose a style or design that they prefer, they will generally choose the one that looks most familiar. -- Blog post 2007/06/12.

Comments on a blog are a bad idea because they often detract from the original ideas of the blogger. If other people disagree, they're welcome to do so on their own blogs, where they have to take ownership of their words. -- Learning from Dave Winer.

The developers who ignore performance and blast ahead adding cool features to their applications will, in the long run, have better applications. Sandboxes didn’t work then and they’re not working now. In the future, there will be an AJAX SDK which will rule them all and in the darkness bind them. -- Strategy Letter VI.

To ensure software failure: 1. use mediocre developers. 2. don't make a detailed blueprint. 3. negotiate a better sounding deadline. 4. re-assign work frequently. 5. work overtime. -- Five Easy Ways to Fail.

If you're demoing software, 1. People will remember the location so pick the nicest location possible. 2. Make the room seem packed. 3. Get a room that is made for presentations. 4. Dress up the location with music, goodies and make people socialize. 5. Make the demo screens as big as possible so people will be able to read what you are demoing. 6. Don't make yourself look like a gopher: lock the door until the room is ready and bring people to do stuff. 7. The only interesting way to design a demo is to make it a story. 8. Be sure to accidentally bump into all the nice little “fit and finish” features of your product. 9. Say all the important points two ways. 10. Practice and re-watch it on a video. 11. Have a follow-up plan. -- How to demo software.

Talk at Yale

Quality of software can't be measured in an automated way because automated tests won't measure some of the most important aspects of software: the look and feel, and usability. --Part 1

It sucks to be an in house programmer, because you will only get the chance to make half baked, ugly programs, and nobody will really care. Part 2

Being able to write clearly on technical topics is the difference between being a grunt individual contributor programmer and being a leader. Part 3

The market pays for solutions to gnarly problems, not solutions to easy problems. The only way to keep growing - as a person and as a company - is to keep expanding the boundaries of what you're good at. And you will be able to solve more gnarly problems. -- Where there's muck, there's brass