Live data from Hacker News

Ask HN: Why aren't you coding?

news.ycombinator.com

281–290 of 316 posts

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

#281
post #184

Earlier quoted context omitted.

> For the same reason our job's don't stop when we go home (or turn off slack) either, we are essentially paid to think and our brains do not care about the arbitrary thresholds set by 9-5. Speak for yourself. Some of us have been there, burnt out and had to rebuild our relationship with work in a healthy manner. I think no matter what you do, if it is thought work and you don't find a wat to turn it off, you are doi…

How do you not think about work outside of work though? My current job is a shitshow, and I would like my thought towards it to only happen 9–5 while I get paid, but my brain is always thinking about whatever I’m stuck writing code about even during my weekend or outside work hours. I don’t work outside work hours but I can’t stop the thinking either. You make it sound like there is an on off switch, but I don’t seem…

This technique helps me break a thought pattern. I ask myself (regarding my situation where I physically am right now and then expanding outwards to my life)

“Is this pleasant?” “Is this unpleasant?” “Is this neutral”

For example, I walk into a room thinking about work, sit down still thinking about work, and finally notice I’m thinking about work, so I ask myself the questions. Is the chair alright? How do I feel? Hungry? Cold or tired? No, this chair and room are comfortable. I’m safe, my family are nearby, I just ate a nice sandwich etc... that’s pretty good.

It forces me back into the present. Added bonus, the moment you label anything as neutral it transforms into pleasant, because anything not unpleasant is pleasant!

You could try it continuously or set alarms or just ask yourself often. Whatever suits you.

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

#282

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

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

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

#284

because im vacuuming the db, flushing the cache, rotating the logs, retrieving the stats, rebooting the server, teaching you to change the background in the chat, commenting on the tickets, adding to the docs, onboarding the noobs, upgrading the libraries, adding ips to the firewall, updating the ssl cert, installing, compiling, backing-up, migrating, doing my timesheets, ive got 3 'training modules' i haven't comple…

"i thought you said some other guy had done it already on github and all you had to do was tweak it." "na. it didn't work the solution ended up being these 2 solutions on stackoverflow that i copied and pasted together." "you're a genius." "thanks"

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

#287
post #227

Earlier 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

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

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

#288
Meetings, most of them without bullet points or a specific topic.

I'm coordinating another devs too and that costs less time then meetings to projects. We don't have the best product owner culture, so I need to fill that role too. But we are working on that topic atm and we are reaching the first goals.

It's funny and I like it, but sometimes I just block time in my calendar to do tasks two weeks ahead. So nobody is able to schedule me on a meeting without asking before.

That makes most people think about if I'm really necessary.

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

#289
post #248
post #167

Earlier quoted context omitted.

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

Just use Java, then your FooClassFactory instance can just be named fooClassFactory :)

[deleted]

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

#290
post #216

Earlier quoted context omitted.

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.

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

Post reply on HN