Live data from Hacker News

Ask HN: Why aren't you coding?

news.ycombinator.com

171–180 of 316 posts

Re: Ask HN: Why aren't you coding?

#171
most of the things I want to "code" have problems with them I can't solve. I don't have the time or money to solve those problems so why start? I have some potential business ideas/big projects but I can't figure out how to make those things pay for themselves and some of the engineering requires solving problems I don't know can be solved.

I can't drop out of my job to start working on them because people rely on the money coming in from my current job which consumes all my time and energy. I could try to raise investor money but as I said, I don't know how to monetize these ideas or at least keep money coming in so no good investor would give me money and I refuse to commit fraud.

Re: Ask HN: Why aren't you coding?

#172
Because I'm updating my work log. Because my employer wants me to keep a log of everything I spend my time on. Or, because I'm updating my ticket statuses. Because my boss wants to see updates in tickets periodically even if there is no progress, so sometimes the udpdate is just "no progress."

Re: Ask HN: Why aren't you coding?

#173
It is probably roughly analogous (I do consulting but not specifically coding), but much of my "down time" truly is "letting the ideas percolate" because properly thinking through what you're planning to do slowly and methodically saves you so much time and frustration in the end.

Of course then there are days when I just don't feel like it. I get paid hourly so I don't feel bad about it. I also get paid over twice what is technically the hourly rate of a normal employee. This leads me to think that companies expect employees to spend half their time doing what I do when I'm not billing them -- letting ideas percolate.

Re: Ask HN: Why aren't you coding?

#174
post #167

I finally checked out the link. You're looking for material to use in a comic? And I'm trying to give you a serious answer. Maybe these experiences will help: Had a coworker get promoted way past his level of incompetence. He never accomplished much before, but afterward he spent all of his time lobbying for his ideas and undermining those of us that were trying to get work done. Wasted a lot of time dealing with him…

> I'm sure a lot of people have this problem: naming things. Can't code until you figure out what that variable should be called. i, j, k, foo, bar, baz, and don't waste a moment thinking about it till your solution is finished and warrants a once-over (or till it has grown sufficiently complicated that a real name is finally necessary even if temporary -- try to work in small enough units that this never happens).

This reminds me of advice I learned in school for writing: if you are having trouble coming up with an introduction, just write as if you already introduced the topic and come back to the intro afterward.

Re: Ask HN: Why aren't you coding?

#175
post #96

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, 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…

Don’t code a prototype!! All your credibility is lost. Get feedback from stakeholders using a mock-up. Iterate on a sketch.

Use that to design features, design schemas, break work down and plan deliverables.

For the love of god, step away from the IDE

Re: Ask HN: Why aren't you coding?

#176
post #96

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, sketc…

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

Re: Ask HN: Why aren't you coding?

#177
post #96

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, sketc…

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

Re: Ask HN: Why aren't you coding?

#178

Mainly because I’m helping other people be able to code. One of the interesting things about the 10x engineer meme is that they’re 10x because they improve the productivity of their team. Well extend that to DevRel and that’s maybe another order of magnitude or two of effect again. Extend that to the average person looking to build and it’s another order or perhaps two again. Hopefully the stuff I’m doing now will ge…

The 10x engineer being an enabler is a nice interpretation but the original definition of a 10x engineer is a skilled engineer working unhealthy hours. The enabler 10x engineer may be true - even though I've never found managers so good to multiply their team output dramatically while I've met 10x engineers building incredibly fast and slaving away for a chance to make millions. It could be that's because I found ena…

> the original definition of a 10x engineer is a skilled engineer working unhealthy hours.

No, your narrative is that of "working unhealthy hours."

Generally a 10x engineer is just said to get 10x more results.

Most successful startups in SV have one.

Re: Ask HN: Why aren't you coding?

#180

Earlier quoted context omitted.

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.

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

Post reply on HN