Hacker News Reader

Comment by anw | Hacker News Reader

Because 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, sketching up drafts of what the house should look like within the constraints available, and then plan the foundation of which to start building.

If they came and immediately just started laying bricks, I'd know I have a really shitty house builder.

I mean no offense by this, but "why aren't you X" is a bit naïve and comes off as lacking a good amount of experience in that field. There are many reasons why not doing X is right, including social/mental recovery and prevention of burnout.

View on HN

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 else. After confirming with another dev in chat that the designer was right, I could start coding.

In the end, after 20 minutes of calls/chat and around 30 minutes coding, the issue was resolved. I saved so much time (days, really) just by being a bit sceptical.

I'm new on the team, so first I thought it is just me who can't follow everything, then asked around and realized that the level of miscommunication is shocking and people don't even realize that they don't understand things and act like everything is trivially simple (the team looks good, though).

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 should be done.

Acceptance criteria are a (good) tool to drive the discussion into a specific, rather than abstract, direction, but should not replace verbal communication.

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”.

I've also witnessed agile being used as a excuse for "We're not going to take the time to understand the problem. We're not going to work with the client so that they understand their own problem. Nah. Insted, just do the work. Do what you're told. If we miss the target we'll fix it in another sprint. They're paying. NBD."

It’s funny because that outcome is almost certainly the opposite of agility. Just do the work and hope it’s what they wanted.

Actually, because I also feel that the word has been used in many contexts and I would like to sharpen the meaning. So you might say, that I could go around an find all things that work aka good practices and say 'This is Agile', but in fact Martin Fowler (one of initial authors), said, that they even discussed calling it 'Conversational' but ultimately choose 'Agile' [1]. I think that example shows, how important verbal communication is, from the perspective of the Agile Manifesto.

[1] https://youtu.be/G_y2pNj0zZg?t=1399

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."

> But methodology should be independent of being able and willing to ask questions.

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.

[1] https://agilemanifesto.org/

Culture > methodology

Culture either allows and values questions and improvememt or it doesn't. If it doesn't then methodology will not override (read: fix) that.

Waterfall or not, or otherwise isn't really relevant. Culture is.

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).

Not to dismiss your point, but I'd like to add that simply adding an "acceptance criteria" section to all tasks also isn't a solution.

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.

Many of the process improvements we have made where I am over the last ten years boil down to "ok, stop, does this still make sense?" at each hand off. It helps that we make data driven decisions so the stakeholders know what they need rather than "yeah, can you make me a button that doubles or revenue?"

Keep communicating with everyone, and you may lead this team in 6 months.

Well, make sure that's actually wanted before jumping into assumptions.

I had the misfortune of assuming people want to communicate more in order to avoid miscommunication but it turned out that the team (~5 developers in a ~15 person company) actually wanted more walls around them, minimize communication and focus on silo'd development (one frontend, one backend, one ios, one android and one infrastructure with 0 sharing of tasks even if one was behind/in front) with as little communication between devs and others in the company as possible. Only the person dedicated for communication should do the communication.

I didn't agree with this so I no longer work there, but there was a few months of pain because I assumed everyone wanted to communicate but didn't have the experience/tools/processes to do so. I was wrong, which took time to discover as I assumed everyone wanted agile collaboration.

> 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 would be accomplished by coding though. You code up prototypes, show them to people, ask questions, test performance, test the different dependencies etc. Making a big design up front as you suggest instead of just coding prototypes is naive and wastes time. It is a good way to look productive to management though, I give you that.

I dunno, if one of my team members was constantly coding up non viable prototypes instead of communicating with people, writing up proposed solutions and alternatives, and seeking a bit of consensus first, that would strike me as a much worse waste of time.

Prototyping takes less time than writing up the requirement in paper. And customers can give more accurate feedback watching the prototype than reading the docs.

It rarely happens that once a prototype is written, the developer finds out it was all a wastage and the customer wanted something quite different.

Think of the prototype as a Photoshop mock, but interactive like the real application.

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 contracted 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 screens.

The team debated and debated on how to fix it, but ultimately it kept getting trumped by the documentation team who said the docs are done so we couldn't change anything. I left after a couple of months. They worked on it for a year before finally tossing it out.

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.

Sure, but a few days of intense dedicated discussions /white boarding with a handful of senior engineers can save you from throwing a bunch of different prototypes at a wall to see which one sticks.

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

I think spending days on planning is really valuable. Spending weeks is counterproductive in most cases.

Figuring out exactly what code to write is not the goal. Figuring out approximately what code not to write is.

The thing is engineers in other engineering disciplines have documentation that lay down things to the minutest detail. So is it not a good idea for software specifications to do the same, instead of having a brief design document missing huge amounts of design details.

Abridged and abstracted documents add their own confusion.

Agreed! And this does not contradict what I said. I think it's easy to swing too far in both directions.

> 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 ultimately it kept getting trumped by the documentation team who said the docs are done so we couldn't change anything.

I left after a couple of months. They worked on it for a year before finally tossing it out.

Well this is obviously also bad. It is not necessary to either dogmatically code without first planning or discussing, or to dogmatically write a fully specified and unchangeable spec. There is a huge continuum of possibilities between those extremes, which strike a better balance than either approach.

> It rarely happens that once a prototype is written, the developer finds out it was all a wastage and the customer wanted something quite different.

In my experience this leads to mediocre results. You need to throw out prototypes often, otherwise you'll end up with shitty solutions.

It's an unfortunate fact that as soon as you see a prototype, everyones instict is to fix the most glaring issues and call it done.

But to get to a truly great solution, you often have to throw out the prototype, and start all over.

Unfortunately very few people have the patience for that. Usually the prototype already took so much time, that everyone is already totally stressed, and starting over is out of the question.

If throwing the prototype away isn't possible, it's not really a prototype anymore.

Prototypes are useful when you already have a pretty clear picture for what you're trying to build and just need to figure out how it's going to work. If you have yet to validate that you understand the what, you're better off talking and whiteboarding than taking time to code up a prototype.

Coding prototypes without design direction, that is the real time waster from my point of view.

Thought travels faster than pen on paper travels faster than code ok editor.

Yep, the answer to this question for me is pretty much always "because I'm communicating", followed closely by "because I'm reading". Coordination and research are a bigger and more important part of my job than coding (which is also important).

If you look at the referenced website, you'll see you're taking the question pretty seriously. To the comic author: I think your work is funny, keep it up!

Indeed. It's like asking "why aren't you nailing pieces of wood together?" or "why aren't you moving your right bicep?".

> There are many reasons why not doing X is right, including social/mental recovery and prevention of burnout.

You suggested the question seems naive, but you’ve also listed plenty of good answers to “why aren’t you coding?”

I’m not sure you can attribute naivety to a simple question like this, and I don’t think it’s necessary. It’s just a question. It’s prompted some interesting responses in this thread.

Interesting how judgment is assumed in this question. A question like “why aren’t you living in Istanbul” feels very neutral, whereas OP’s question can feel like a moral suggestion. Seems unfair to presuppose such things, though especially in a caustic way

I'd definitely also treat a question “why aren’t you living in Istanbul” as non-neutral with an implied assertion that in the absence of any specific argument it the natural choice would be to live in Istanbul; it's pretty much the nature of any question in the form "why aren't you doing X".

Agreed.

And I’m fascinated by some of the responses to this question, including the post I was responding to. It’s really interesting.

I come with my own bias, I’d like to code more, and arguably need to, but don’t always manage the non-coding side of my work in the most optimal way.

Really interesting to read everyone’s thoughts.

This is a bad analogy. Coding is closer to writing a book than building a house. The faster you start hacking prototypes the better. As long as you are ready to throw virtually all of it away. Most of you assumptions during planning are wrong anyway so there is little point in planning too much.

The worst thing that happened to coding is business culture with design docs, architecture docs, whatever docs all coming before a prototype is written. This is how you end up with "enterprise grade" garbage.

The best way to create a good code base is to write it inside out a few times over. Documents ain't gonna help you.

I think you’re right but that doesn’t mean the questioner is naive or inexperienced. It’s a legitimate question with lots of potential interesting answers.

Coding can be all of those things if you're doing it right.

> Because Coding is not Working

Then what is it?

Coding is part of working but not the full story. Problem solving (especially analysing and designing) is the most important part of the work. To do good work you think hard, solve the problem, and then code the minimum necessary to make it work outside your brain.

It's necessary but not sufficient.

And arguably it's best when it's done as little as possible.

I write better non-trivial code when I get up and get away from the screen for a while. Go do something else to get my mind off it. Even sleep on it. Then the insights creep in. Hammering away at a hard problem usually makes a big mess. Sometimes three quarters of my time is spent understanding the requirements, negotiating the solution, researching, talking through the design.

Same here! Sometimes I’ve spent weeks thinking through a problem fully, talking to everyone involved (including myself) only to code whatever it was in a couple hours. It’s amazing what our brains can process subconsciously.

Related to this, I typically advocate for the daily stand-up close to mid day so that more work gets time to "sleep on it" and then a chance to add any insights that came to you during the off time. I seem to do better features and code over two work sessions than in one long continuous day.

You don't think that coding a prototype in a few hours before talking to people would let them better answer your questions and help reduce that time to a few days instead of weeks? Coding is a very versatile tool and can be used to greatly improve communication.

If it's a very specific problem and you have a candidate solution already known, sure. If it's a vague problem or if you just don't know how to solve it, a prototype would do much less, and is probably a waste of time.

In particular, architectural discussions benefit pretty little from prototyping in the initial phases. If you want to decide if your next system should be microservice based or monolithic, prototyping won't do much.

Similarly, if the basic requirements are not yet understood, asking questions about them is more efficient than implementing a version of possible requirements and asking others to correct it.

> Hammering away at a hard problem usually makes a big mess

How can this be? Did you never learn how to use source control? Coding is the best way to explore the solution space, doesn't mean you use whatever you write right now.

Coding is a good way to explore the solution space, but not the best or only way.

My current guidelines for myself are

1. Take a few minutes (or hours, depending on problem size) to write a clear plan for a proof of concept. What's the terrible, crappy, bare minimum that shows your goal is feasible?

2. Run that document past another person. See if they can simplify the plan for you or find things you overlooked.

3. Hack out the POC.

4. Run the POC past a real person. See if they catch issues in your approach that would be blockers in a production version and resolve them if possible.

5. Write the spec for the actual feature/program based on what you learned from the POC. It doesn't need to be super-detailed or perfect; it just needs to capture the lessons you've learned and give a clear direction for building the real thing.

6. Run the spec past another person. Incorporate their feedback.

7. Write the production version.

This works out pretty well if you keep your specs as plain text in the project repo. You can do the whole process with a standard code review flow.

Code tends to be a liability rather than an asset.

A no code solution to a problem tends to be better than one with code

For me, coding is a great way to explore the solution space when you're down to the last few details. Because coding is implementing a concrete solution, exploration in code tends to only cover a very small subset of the real solution space. On the other hand, if I take a few steps back and look at the problem from a wider angle, I can often find a solution that is both better for everyone and easier to implement.

Code forces you to solve all the details. If (you think) you're close to a solution, sure, then yes, hammering away is a good thing.

But if you're still at the big picture level, code is a horrible way to express that. It inevitably takes you into the weeds.

It's sufficient but not necessary.

Reasoning:

If you're coding, that counts as working. But if you're working, that doesn't mean that you are coding.

Obviously yours works too though (You have to do some programming, but you also have to do other things).

> Because Coding is not Working.

Implementation is work. It's a phase in the SDLC.

> Coding is not Accomplishing Goals.

If the goal of a particular task is defined as a code deliverable, then coding will help you accomplish that goal.

I think the OP could be better expressed as "coding is not the only kind of Work".

It's possible the question is meant as "in the context of wanting to code and having something to code, what is impeding your desire and goal to code at the moment?".

Look up "tracer bullets" in the Pragmatic Programmer. Basically you create an end-to-end working system that capture just enough functionality to work, then you show the user and use their feedback to adjust your "aim" for the next version. Rinse and repeat. I've tried this and worked pretty well.

Solid. Mind if I sum it up?

Coding is a means, not an ends.

Working hard is easy. Working smart is hard.

I think you got that backwards.

Working hard can become very cumbersome and/or annoying to deal with from a team perspective if you don't align with your team/customers/stakeholders/etc.

Reply on news.ycombinator.com