musingstudio

Plenty of good ideas here from Jeff Atwood. I love the passion he shows for his new venture:

Have your team and yourself start using that minimum viable product, every day, all day long. This is way more than mere software development: it’s your whole life. If you aren’t living in the software you’re building, each day, every day, all day … things are inevitably going to end in tears for everyone involved.

Now, need a customer service mindset for this approach, and a band of dedicated, cross-discipline engineers prepared to roll up their sleeves and get things done. But if you have that spirit and belief, the project can succeed.

The only thing I’ve ever seen work is getting down deep and dirty in the trenches with your users, communicating with them and cultivating relationships. That’s how you suss out the rare 10% of community feedback that is amazing and transformative. That’s how you build a community that gives a damn about what you’re doing – by caring enough to truly listen to them and making changes they care about.

This paper by Dijkstra was linked from a discussion on ArsTechnica about system design. It’s amazing that many of his high-level points remain true today, despite being published in 1968 – I’ve picked out a few below:

Focus:

Production speed is severely degraded if one works with half time people, who have other obligations as well. This is as least a factor of four, probably it is worse. The people themselves lose time and energy in switching over, the group as a whole loses decision speed as discussions, when needed, have often to be postponed until all people concerned are available.

Star developers:

The intellectual level needed for system design is in general grossly underestimated. I am more than ever convinced that this type of work is just difficult and that every effort to do it with other than the best people is doomed to either failure or moderate success at enormous expenses.

Unit testing:

It seems the designer’s responsibility to construct his mechanism in such a way —i.e. so highly structured— that at each stage of the testing procedure the number of relevant test cases is so small that he can try them all and that what is being tested is so perspicuous that it is clear that he has not overlooked a situation.

I’d add to the list that it’s vital to spread knowledge within a team to maintain productivity and avoid one person being silo’d to a specialist skill and becoming a bottle neck. Instead, find out how to pull the source code out of the repository, how to build and test it – and start making small changes yourself as a learning exercise.