Hodgeblot

Software

A 39 post collection


Why Mark Zuckerberg and Michael Bloomberg Are Having the Wrong Debate Over Job Training | Inc.com

 •  Filed under Technology, Software, Coding, Stupidity, Bloomberg

Why Mark Zuckerberg and Michael Bloomberg Are Having the Wrong Debate Over Job Training | Inc.com

Bloomberg saying "you can't teach a coal miner to code" is worse than offensive. It's akin to saying "you can't teach a slave to read." He should be called to account for it.

While his larger point about needing a variety of solutions to unemployment problems is fair, coding is a skill exactly like reading and writing any natural language. No one would hold up Hemingway or Tolstoy as a reason not to teach reading and writing, so please don't do it for technical skill. You don’t have to land a job as a senior engineer at Google or Facebook to develop coding proficiency and benefit from that knowledge. We live in a technological society now; people should be encouraged to adapt, not discouraged.

Silicon Valley's Youth Problem

 •  Filed under Technology, Startups, Software, Web, Silicon Valley

Silicon Valley'™s Youth Problem

A real great article. At places early on, it borders on youth bias, likely because the guy writing it is in grad school and doesn’t realize his own bias. But once you get passed that, the piece has some excellent insight and ideas as it carries along. Good stuff.

Settling on a development process

 •  Filed under Software, Development, Process, Dev Process, Agile, Agile Methodologies

We’ve been chatting about dev process at work, and I’ve come to realize most people settle on a dev process all wrong. People either pick one from some agile religion they’ve bought into – “scrum is what everyone is using” or “lean is so hot right now” – or they pick a little here and there from different philosophies, with no real clue what works or doesn’t work. My advice: figure out what you value first and match your dev process to those values.

We all spend a lot of time figuring out what we value in our products – easy to use, elegant, does ‘X’ better than anyone else, and so on. We need to spend just as much time figuring out what we value in how we build that product.

Do we love iteration? Do we love getting the product perfect before showing it to users? Do we value an engineering-driven culture? Or do we love cross-discipline teams?

Once we answer these sort of questions, we should match our development process to those ideals. Pick a process that reinforces what you value. With this approach, you won’t pick too much process or pick a process that doesn’t work for you. Settle on just enough process to reinforce your values and support your team. Perfect!