Hacker News Reader

Comment by js8 | Hacker News Reader

I quite strongly disagree. Just like picture is worth a thousand words, working code (prototype) is worth a thousand words too.

If I decide to go out and code a prototype without asking anyone anything, where is the harm in that? You can criticize it after it is done. You could have done the same thing. And you can always throw it out.

And in my view, this precisely is "leading by doing". Linus Torvalds didn't seek consensus before he wrote Git.

In another response, you write, arrogant people are the biggest problem. I don't think doing something on your own is arrogant at all.

And I think, "being accountable for consequences" is exactly the "forgiveness" part. Although I am not a fan of hierarchical decision making systems.

View on HN

Wouldn't coding up a prototype be more in line with asking for permission? You code up the prototype to demonstrate your idea then ask your team if you can proceed with it. I would say that's a solid, proactive way to get your ideas across.

Better to spend 4 days working up a prototype than spend 4 days trying to persuade people to let you work up a prototype

Depends on your working environment. At my current position, if I code up a prototype during work hours, I'm subverting our EPMO, since it's not an approved project. I've had great success doing various prototypes like this, but I am not waiting for permission to do them.

Bringing those prototypes to production is another matter. In any organization, there are processes that need to be followed to onboard a new application, platform, pattern, etc. If those aren't followed, the implementation won't be nearly as effective—especially long-term.

What is an EMPO?

Indeed production is another matter.. "I'll just slip in this new crypto routine I wrote and ask for forgiveness later..."

Oops—should have been EPMO (enterprise project management office).

Hmmm... What is an enterprise project management office?

> Hmmm... What is an enterprise project management office?

It's the office responsible for processing TPS reports.

It sounds like a normal project manager/owner but with with the bureaucracy turned up to 11.

Pretty much. They're responsible for managing the project pipeline, prioritizing, sequencing... Basically, they're meta-PMs.

This is at a 25,000 employee healthcare system. Bureaucracy is inevitable, but agility is still essential.

In some work environments, you are encouraged to get 40 hours a week, regardless of whether those 40 hours are necessarily put towards what are perceived as the "highest value" endeavors. So if you are blocked on everything else, why not take the remaining time and put it towards things you personally believe to be beneficial to the project? It is certainly better than sitting on your thumbs or asking people who are already busy what they think you should be doing.

Is this work in lieu of your regular tasks? If not, clearly you don't have enough to do. If so, that's grounds for dismissal. Unless, you got permission...

You must work at an awful organisation.

Wait, there's organizations that let devs spend hours on a prototype in lieu of their normal work?

Wasn't Google famous for giving devs 20% play time to work on whatever passion project they wanted?

That is my normal work.

Our manager doesn't have a clue how systems work, so it's up to us to find the best way. I know the various areas we need to develop to push the system forward and it is up to me to find the best way to do it. If I learn something new that makes me rethink something, then I am more than welcome to revisit it and try out some new things. If it ends up with a better system then we all benefit. At the end of the day the work that needs to get done does get done.

Obviously I do have to use my judgement to allocate time appropriately. If there is a customer screaming at accounts because they were overcharged or whatever, then it is quite obvious I need to resolve that issue rather than work on a new way to style our buttons, but for the majority of the time it is up to me.

I do also spend quite a lot of my own time working on various things where it is a bit ambiguous as to whether it is 'proper' work or not. I enjoy the work I do because I don't feel like I am working in a sweat shop..

Maybe I'm just lucky to have always found a job where management trusts the developers.

Yes! I would be really surprised if an organisation didn't expect that to happen!

When solving pretty much any problem that I don't have an existing cookie-cutter solution for, I do some prototyping as part of the process of figuring out how it works. Sometimes I do this for arbitrary things that are irritating me, or that I think might be worth looking at.

Nobody is sitting over my shoulder looking at everything I do and I'd be right out the door if that was ever the case. I'd expect professional software engineers to spend at least a bit of their time working on this sort of stuff!

> When solving pretty much any problem that I don't have an existing cookie-cutter solution for, I do some prototyping as part of the process of figuring out how it works. Sometimes I do this for arbitrary things that are irritating me, or that I think might be worth looking at.

Well, of course this is how normal development works. This is the work I am talking about that would _not_ get done because the OP was working on a prototype to solve some _other_ problem.

> I quite strongly disagree. Just like picture is worth a thousand words, working code (prototype) is worth a thousand words too.

Working code is the easiest part. No one every throws it out and we are doomed to maintain the shitty prototype code for years. I find for internal software / consulting: "working code, ends arguments" but for enterprise software it is exactly the opposite.

It's idiosyncratic code that doesn't scale to a team developing it. It's has no tests and no thought to broader usage. There is no documentation. It fails apart after you put load on it, want HA, load-balancing, disaster recovery. Almost all code works at the small scale. It's so hard to prove to even mid-range developers why an architecture that "works" doesn't really work.

When you mix developers coming from the opposite spectrum it is disastrous.

You're implying that a prototype is a form of communication, which I strongly agree with.

I think the key thing here is to ask "What is the impact on other people if I just do the thing?"

In the case of building the prototype, its either "Well, now they need to spend time looking at the prototype", which would be the case no matter what communication medium you used or its "Well now JS spent 4 days doing that instead of what was on the roadmap. On the other hand, we have a prototype of X" which is a bit of a gamble and depends on what people were depending on you for.

> If I decide to go out and code a prototype without asking anyone anything, where is the harm in that? You can criticize it after it is done. You could have done the same thing. And you can always throw it out.

I don't understand this point. Are you suggesting coding a prototype on your own time? Otherwise if everyone in a team is free to choose to code prototypes who gets the actual work done?

Reply on news.ycombinator.com