Hacker News Reader

Comment by Buttons840 | Hacker News Reader

Most programmers program for fun in th their free time. If you want to motivate us, then don't do things that demotivate us and you'll find us motivated.

What demotivates me are meetings with outcomes I don't care about. I don't care about story points, and meetings focused on story points demotivate me. I'm demotivated by sprints followed by another sprint followed by another sprint; the problem is right there in the name. I'm demotivated by deadlines I cannot comfortably meet and other dictates passed down from above.

View on HN

I don’t think most programmers code for fun in their free time. I do and know quite some who also do code for fun but still….

Story points and sprints are there to save you from people who would otherwise come to you and ask for changes or shift priorities on daily basis.

You don’t care about story points but with them you can say “I am busy with this 8 pt story will pick next when I am done” instead of having some pointy haired boss insisting to do something else each day and after a month yelling at you “why nothing is finished”.

> I don’t think most programmers code for fun in their free time.

Maybe not, I haven't done a study. But literally every dev that I personally know (well enough to know what they do in their free time) does this.

> save you from people who would otherwise come to you and ask for changes or shift priorities on daily basis.

The problem is that one of the jobs of a manager is to shield devs from this. A manager who is bad enough that they aren't able to do that is probably also a manager who won't stop (or may even take part in) the abuse of Agile mechanisms as leverage over the devs.

I think this problem is one of the main reasons why agile is largely a failure.

> But literally every dev that I personally know

Your bubble is absurdly tiny. I assure you this is not the norm across software engineering as a whole.

You have no clue how large or small my professional circle is.

Since you claim to have knowledge about what is the norm across the entire field of software engineering rather than just the people in your own bubble, I assume that you have a study that informs your belief?

Maybe it is fair to say, probably 50% people develop for fun outside work, and another 50% don't?

That's an OK prior if you have literally no other information, but still isn't reasonable once you know anything about people.

In the absence of data, saying this is just as speculative as saying any other ratio. There's no reason to think any particular ratio is the correct one.

That's why I was very careful to point out that I was talking about my personal experience, and wasn't generalizing it to the field as a whole. I have no data to support any speculation about the field as a whole.

There are an estimated 28 million software developers in the world. How many millions do you know personally?

Your circle is incredibly small.

Everyone's circle is incredibly small by that definition, and those neither opinions hold any weight.

Literally zero of the devs I know spend a nontrivial amount of time coding for fun outside of work. Maybe a few small things once a year or so but hardly what I’d consider regular. We do often do ‘fun stuff’ at work though so it kind of scratches that itch

The problem is that once upon a time, someone wrote a management book that said that setting deadlines can push people to work harder — and to an extent that's true — but if you take that idea to the extreme and every week is an important deadline, eventually the magic runs out and you end up just burning everyone out. Good managers know this of course, and work hard to find some kind of a balance between their team, higher management, external parties etc. Bad managers operate on auto and do whatever is currently en vogue.

Problem with sprints is some people treat those as deadlines- while end of sprint is just a checkpoint.

What was delivered what was not delivered- then we can ask why something wasn’t delivered. We can ask is what we build still relevant? Maybe we need to cut some.

Very important to identify if some issues will take more than one sprint and still break it down as much as possible and figure out what needs to be stubbed out that first sprint. I am not huge on the process, but too many people dont take full advantage of what seem like obvious ways to keep yourself out of trouble, and if for some awful reason you miss the deadline regardless, document everything that has been finished, and create new follow up tasks for the next sprint. No need to freak out and continue a task over unless it was one of the last tasks assigned.

I prefer to just try and simplify the process and ensure people dont feel more stress than is healthy. Deadlines are always ideal, they are never truly sensible because you cannot foresee a problem down the road with the design until enough ground has been broken. I have seen managers ask near the end who approved an approach and yet they are the only ones in the room who do that, but nobody wants to tell the guy who can fire you that they in fact made the bad call.

In my experience a miniscule proportion of programmers code for fun.

Maybe the parent post is exaggerating a bit, but I think that at least it is fair to say that most good programmers began programming just for fun. And when managed well and presented with interesting problems, they will become highly productive and self-driven.

Again, inaccurate. There is a self-selection process at work here in certain roles and domains, maybe, but to boldly claim that your bubble is a representative sample of the entire industry is naive.

What the OP said is backed by large studies. For example, the HackerRank 2020 study (n=116,000) found that developers who code for fun tend to score higher on skill assessments.

The statement in my previous post, where I claimed most good programmers began coding for fun is also reasonable.

Having studied CS in a large state school, I did not find any student that did not begin programming for fun prior to enrolling at university.

I understand that this may not hold for every possible case, e.g. programmers without a CS degree that discovered programming later on, but it is still pretty reasonable.

I think it is valuable to step back and see why meetings exist and then try to fix them if they are not addressing their purpose.

Meeting are valuable because they are solving a coordination problem. Without meetings people would be misaligned.

I want to have fun programming but I also want to make sure I am working on things that are important to the business and to the customers. Meetings help in navigating that vague space.

Reply on news.ycombinator.com