News for hackers. Stuff that matters.
Re:The Case for Slow Programming by pjmorris on Monday December 01, 2014 @05:34PM (#8684418)
Should you measure the worker, or measure the work?

Anyone who can build reliable systems using unreliable parts (like humans) will have an edge.

EDIT: If you're going to measure the worker's programming concept knowledge, Alison Tew's work seems to be at the leading edge.

[1] 'Developing a Validated Assessment of Fundamental CS1 Concepts', Tew, Guzdial, http://dl.acm.org/citation.cfm?id=1734297

Re:The Case for Slow Programming by hasenj on Monday December 01, 2014 @05:47PM (#8684500)
I'm more interested in measuring abilities relevant directly to software as a profession (or craftsmanship), such as: how well can you architecture a system to solve a complex problem?
Re:The Case for Slow Programming by wellpast on Monday December 01, 2014 @06:40PM (#8684813)
This is important: you can separate handling complexity from the profession of building architecturally sound systems.

We can teach people how to do math correctly. That doesn't guarantee that they will be able to solve arbitrarily complex problems. But to solve math problems, you MUST at least have the skill sets.

So there is a test to measure do you have the skill sets. How much one is willing and/or able to handle complexity is a separate thing to consider.

Re:The Case for Slow Programming by eru on Monday December 01, 2014 @05:53PM (#8684547)
If you can shine a new light on the problem to make it simple instead, than you can get away with a simpler architecture.
Re:The Case for Slow Programming by lsiebert on Monday December 01, 2014 @06:25PM (#8684732)
Thanks, that was a very interesting paper (though I had to google to find a copy).