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.
Ask HN: Why aren't you coding?
171–180 of 316 posts
Re: Ask HN: Why aren't you coding?
#172Re: Ask HN: Why aren't you coding?
#173Of 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?
#174I 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).
Re: Ask HN: Why aren't you coding?
#175Because 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…
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?
#176Because 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…
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?
#177Because 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?
Re: Ask HN: Why aren't you coding?
#178Mainly 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…
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?
#179Re: Ask HN: Why aren't you coding?
#180Earlier 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.
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.