21–30 of 30 posts
"Weeks of programming save you hours of planning" edit: apparently this is paraphrased (beyond the obvious). see https://en.wikiquote.org/wiki/Frank_Westheimer
[1] https://www.agendashift.com [2] https://www.agendashift.com/done
My company has quite a few IT architects (the "senior" ones are the worst). They always accuse you of "solutioning" when you propose something, drag you through weeks of meetings, produce a lot of documents and when they are done, they either do nothing or propose a "beautiful" solution that only works on paper. After going through this a few times I have concluded it's easier to whip out a few prototypes for differe…
Iterating can take many forms, and different teams have different workflows. For my work, I would rarely be able to make a "quick prototype" even if I wanted to, since most of my projects need to modify other people's code. And they have to be deployed to be validated. In those cases you better have some consistent plan that everyone agrees on before anybody else lets you touch code that they are responsible for. Yes…
Yes, prototypes have to be deployed. That goes for everyone's prototypes. That's how you get feedback on them. If it's a big deal that you have to deploy your prototypes, find the smallest step you can towards deployments that are less of a big deal and take it. Then repeat.
Paper engineering is never better than just trying out the thing in the real world. Most engineering professions have transaction costs that make this impossible. We have the ability to lower those transaction costs, if we just make the right effort. Come on, do it! It will be fun.
(And "that doesn't work here" has been debunked so many times. It does work also for you.)
My company has quite a few IT architects (the "senior" ones are the worst). They always accuse you of "solutioning" when you propose something, drag you through weeks of meetings, produce a lot of documents and when they are done, they either do nothing or propose a "beautiful" solution that only works on paper. After going through this a few times I have concluded it's easier to whip out a few prototypes for differe…
However, what I missed was a "problem doc". Something for when I just have an idea for a problem to work on, but forcing myself not to share a solution. Something that triggers brainstorming in the reader, and perhaps the right place to also ask "is this the right problem?"
(The article itself seems to just be about https://en.wikipedia.org/wiki/XY_problem)
“Don’t just do something; stand there !”
While working at Google, I came to appreciate design docs. They're a way to help think through the system design, and help communicate the goals, decisions, etc. at a high level. It also provides experts with a place to put in checklists, to encourage me to answer how e.g. privacy is affected. However, what I missed was a "problem doc". Something for when I just have an idea for a problem to work on, but forcing myse…
While working at Google, I came to appreciate design docs. They're a way to help think through the system design, and help communicate the goals, decisions, etc. at a high level. It also provides experts with a place to put in checklists, to encourage me to answer how e.g. privacy is affected. However, what I missed was a "problem doc". Something for when I just have an idea for a problem to work on, but forcing myse…
Did the Google design docs follow any guides on how to structure/present the information and how to draw the line between too little and too much detail?