Earlier quoted context omitted.
You aren’t writing up UX requirements. You’re writing system designs. If you’ve never had to write down and get feedback on a system design that is entirely okay, but as you work on projects of increasing complexity and scope, it becomes more and more important to plan before you write. The prototypes you’re describing are primarily useful for UX iteration, not system design.
> it becomes more and more important to plan before you write. I'll counter that with a real-world experience. I worked at a well known company that did system design & documentation first, without doing prototyping, etc. My first day working on the UI I pointed out that the web app had so many menus that the actual content would barely fit on a 15" laptop screen. The team debated and debated on how to fix it, but ul…
Ask HN: Why aren't you coding?
291–300 of 316 posts
Re: Ask HN: Why aren't you coding?
#292Earlier quoted context omitted.
You aren’t writing up UX requirements. You’re writing system designs. If you’ve never had to write down and get feedback on a system design that is entirely okay, but as you work on projects of increasing complexity and scope, it becomes more and more important to plan before you write. The prototypes you’re describing are primarily useful for UX iteration, not system design.
A short system design doc with a working prototype is vastly superior to a 50 page design doc with no code. Think of it as the scale model of the house in the original example. It’s a way for sake holder to see and feel what they’re going to get.
Re: Ask HN: Why aren't you coding?
#293Earlier quoted context omitted.
A short system design doc with a working prototype is vastly superior to a 50 page design doc with no code. Think of it as the scale model of the house in the original example. It’s a way for sake holder to see and feel what they’re going to get.
Controversial as it may be I completely agree. Maybe I’m just not on the same god tier level as the rest of you but I have done the days/weeks of planning carefully without touching anything close to code “because you’re not supposed to” and there still ends up being things we didn’t think through that become obvious at implementation time. I agree that coding and planning don’t have to be mutually exclusive
Re: Ask HN: Why aren't you coding?
#294Earlier quoted context omitted.
Good point, happened to me today. The UI requirements to my ticket didn't make sense. The changes the other dev wanted would have took us possible days. I was hesitant to start, so I asked another dev... He said something totally different, he kept referring to something the designer wanted, but it didn't make sense to me, either. I called the designer and she told me she never said that and we agreed on something el…
You are 100% correct. This is why Acceptance Criteria are a thing: so the person working on the ticket knows exactly what it means to be "Done". If they're unclear, they must be made clear (by questioning as you did). Often, unclear description or Acceptance Criteria means that the ticket hasn't been though out properly and needs to be clarified (or scrapped).
I've just recently encountered a ticket from a certain person that does this all the time. The problem is that their criteria still only describe the solutions they imagined themselves, which are often… very suboptimal.
In the end, what you want is someone who is capable and willing to properly root cause a problem and weigh multiple possible solutions against each other. If nobody does this, no amount of superficial process will help you.
Re: Ask HN: Why aren't you coding?
#295Re: Ask HN: Why aren't you coding?
#296Earlier quoted context omitted.
Just in case you aren't aware, but this is what agile is actually about. Big part of it is communicating with the team. Not having a fixed plan and adjusting when having new insights is also part of it, but I think the communication part is often overlooked. In the classic methodologies, you had some document, that told you what to do. In agile you should talk about things and just use a few notes to summarize what s…
Perhaps. But methodology should be independent of being able and willing to ask questions. A close colleague recently left a company because the talk was "we're agile" but the walk was "don't ask questions, just do what you're told."
What if asking questions significantly increases quality and productivity? I mean, strictly speaking, Agile is no methodology but more a set of values [1], that defines a culture rather than a methodology. Yes, there are agile methodologies (Scrum, XP, etc.), but those are worthless without the right culture.
In fact, I think you are better off with the waterfall methods, if your company has no ambitions of changing the culture. So the correct combination of culture and methodology is critical.
Re: Ask HN: Why aren't you coding?
#297Re: Ask HN: Why aren't you coding?
#298Earlier quoted context omitted.
Just in case you aren't aware, but this is what agile is actually about. Big part of it is communicating with the team. Not having a fixed plan and adjusting when having new insights is also part of it, but I think the communication part is often overlooked. In the classic methodologies, you had some document, that told you what to do. In agile you should talk about things and just use a few notes to summarize what s…
Why do you have to ascribe good practices such as confirming work necessities as being “Agile” or not? The word (as a proper noun) to me has lost all meaning having been inane different workplaces, all of which claim to be “Agile”.
Re: Ask HN: Why aren't you coding?
#299I feel this way because over a year ago I began a project in the hopes of answering a single question. Every day I am looking for information that might help me answer that question.
Some people would argue that I should stop trying to answer the question and instead try to test things in code. That the process of coding will help me solve the problem. For this problem, I disagree. There is so much I don't know that sitting down and testing things feels like a waste of time. I refuse to program until I have the structure of the program cemented into my brain. Not every single little detail, just the big picture.
When I program, I am chasing an idea. And if I don't fully understand that idea, then programming it becomes so much more difficult.
Re: Ask HN: Why aren't you coding?
#300Because Coding is not Working. Coding is not Planning. Coding is not Being Efficient. Coding is not Accomplishing Goals. Coding is not Saving Money. Coding is not Gaining Customers. I am getting paid to get things done in a good manner. If I wanted to have a house built for me, I would not expect to pay somebody and immediately have them start laying bricks without them looking at the land, taking soil samples, sketc…
> I am getting paid to get things done in a good manner. If I wanted to have a house built for me, I would not expect to pay somebody and immediately have them start laying bricks without them looking at the land, taking soil samples, sketching up drafts of what the house should look like within the constraints available, and then plan the foundation of which to start building. In the software world most of those wou…