4 ms·
I think you're missing the point here. The point isn't coding in isolation is good, nor that we shouldn't break our work down into smaller tasks, it's that the
by pionar 6y ago
I think you're missing the point here. The point isn't coding in isolation is good, nor that we shouldn't break our work down into smaller tasks, it's that the developer should be given the responsibility and freedom to decide what those tasks are for their work, not dictated from above.
If I'm responsible for project A, I should be able to make 85% of the decisions for that project. Too often, recently, development organizations make every decision from above, then break that up into miniscule tasks that require no thought from developers.
Hackathons, IMO, are just gimmicks to gloss over a deficient product management group or software architecture. If your organization can't be convinced of the need to spend time on something outside of a gimmicky "hackathon", then something needs fixed.
- algeoMA 6y agoI don't think hackathons are always a gimmick, but then again I was probably too loose with my word choice. I mostly meant a period of sustained cooperation with a small group where most of the time is spent together, all meetings are canceled, and you don't try to split up work into bite sized pieces with any formality (like a story/jira ticket). I agree that organizations that don't trust their engineers with any design or implementation decisions are wasting their talent and probably creating a lot of bored and burned out engineers. If an engineer wants to use a fancy new piece of tech and they can justify it, let them do it.