Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You've only added two lines – why did that take two days?

mrlacey.com

Post reply on HN
Print view View original

381–390 of 522 posts

Re: You've only added two lines – why did that take two days?

#381

Post by raducu »

elnygren wrote: post #376

An alternative take to this article would be that this person wasted two days because he was reluctant to ask more questions from the person who filed the bug report. How often do you actually receive quality bug reports at work? My experience is that external or internal users almost never provide sufficient information and you as a coder are always expected to drill down on what they reported with a barrage of ques…

"I try and do as much as I can with the information provided."

I know I'm guilty of this one, and I've stayed away from high paced jobs and appreciate jobs where people are ok with my reluctance to bother a lot of people even if that means it takes me longer to figure things out on my own.

This also means I build a much deeper understaning of the systems I work with, or at least I like to think so, and some people have confirmed that about me, indirectly, by praises of my insights.

Re: You've only added two lines – why did that take two days?

#382

Post by rado »

ftio wrote: post #89
caymanjim wrote: post #31

A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…

Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody…

One of the most important lessons. It must be presentable, however extra effort and time it would take.

Re: You've only added two lines – why did that take two days?

#383

Post by lukeramsden »

Piskvorrr wrote: post #368
sincerely wrote: post #353

Earlier quoted context omitted.

On the other hand, this is my profession and I still have no idea why Twitter has so many engineers.

Ah, the eternal temptation: "but that's Easy! I can tackle this single-handed! produces a minimal, text-only prototype which scales enough for a couple thousand users "

Scaling for infinite users as a solo developer is easy, just go Serverless!

Just make sure you have infinite money first.

Re: You've only added two lines – why did that take two days?

#384

Post by mekkkkkk »

rawoke083600 wrote: post #349
caymanjim wrote: post #103

Earlier quoted context omitted.

In a company that understands and embraces agile software practices, this works well. You demo small things that are done, and prototypes are understood as just mockups designed to drive future work. Alas not everyone in power gets it. In more egregious cases, I've been in adversarial environments where teams were pitted against each other to appear "more done." Obviously a recipe for failure. I'm fortunate enough to…

Urg agile, scrum, some-other-magic-words I've come to realised this, "true" agile is more like being funny and smart(not that I am either). If you have to tell people you are smart or funny, you probably are not. Ever noticed how smart people(the really clever ones) are just absurdly smart without walking around telling everyone "hey I'm smart", usually the nicer they are the more intelligent they are(yea you get exc…

It feels like "agile" is such an overloaded word these days. In most settings it just means a specific workflow centered around Scrum or to a lesser extent Kanban. The only true difference from old school waterfall and month long specs is shorter iteration cycles. A "sprint" or "iteration" is still treated as a rigid block of work.

On the other hand if you have a look at the original Agile Manifesto[0] it is a different beast all together. It specifically seems to go against using set processes altogether and basically boils down to nurture organic communication, to adapt and focus on getting shit done.

I suppose the "agile" in the former sense is a compromise to edge closer to the latter, while still maintaining a familiar corporate structure.

EDIT: [0] https://agilemanifesto.org/

Re: You've only added two lines – why did that take two days?

#386

Post by arethuza »

caymanjim wrote: post #31

A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…

"They simply don't understand that the backend functionality is what's doing the bulk of the work"

The truth is that in a lot of cases nobody has ever bothered to explain it to them. What I tend to find in a lot of situations is that managers often prefer younger and/or less experienced developers because they can be bullied - but the reality is that this also means that people are then unlikely to tell their managers what they need to know. Ultimately it is the managers creating the problem, but in most cases (mind you not all) the managers don't understand that they are creating a problem.

Re: You've only added two lines – why did that take two days?

#387

Post by corin_ »

raducu wrote: post #381
elnygren wrote: post #376

An alternative take to this article would be that this person wasted two days because he was reluctant to ask more questions from the person who filed the bug report. How often do you actually receive quality bug reports at work? My experience is that external or internal users almost never provide sufficient information and you as a coder are always expected to drill down on what they reported with a barrage of ques…

"I try and do as much as I can with the information provided." I know I'm guilty of this one, and I've stayed away from high paced jobs and appreciate jobs where people are ok with my reluctance to bother a lot of people even if that means it takes me longer to figure things out on my own. This also means I build a much deeper understaning of the systems I work with, or at least I like to think so, and some people ha…

Their praise is obviously great for knowing how you're doing, but it doesn't confirm the reason for your good insights. Plenty of people manage to be good at what they do without doing 100% the best way possible, so maybe you'd be even better if you changed your approach!

Of course I know nothing about you so I'm not trying to give advice, just replying about the "confirmed" being a potential cognitive bias.

Re: You've only added two lines – why did that take two days?

#388

Post by hvidgaard »

fphhotchips wrote: post #172
0xEFF wrote: post #20

Earlier quoted context omitted.

It’s better to find ways to make more money than to save it. There’s a floor but no ceiling in much of what we do.

This heavily depends on the industry you're in. In software, yes this may be true, but in low margin industries it's absolutely not. The maths is simple. If my margin is 1%, and you make me an extra $100, I keep a buck. If you save me $100, I keep that whole $100. If I'm smart, I can use that to drive my prices down, and take more market share without reducing my margin. Obviously it becomes less clear if your margin…

If it's a high margin market, you should absolutely focus on capturing more revenue, it gives you more available capital to work with. Once that slows down or you get competition, you can focus on improving your efficiency.

Re: You've only added two lines – why did that take two days?

#389

Post by nicbou »

ftio wrote: post #89
caymanjim wrote: post #31

A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…

Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody…

That's excellent advice. I can see how demoralizing it could be to work on something you've already demoed.

Re: You've only added two lines – why did that take two days?

#390

Post by nhlx2 »

nhlx2 wrote: post #366
kgermino wrote: post #266

Earlier quoted context omitted.

> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. I take a different but similar approach when I run into situations where I want to get something small in front of a business user before it’s completely ready: I make sure it’s visibly broken in a way that doesn’t detract from my goal for the meeting. For example: I have a registration form that I want to talk th…

Spot on! I like the “conplete”. I hope it was intentional.

Or even better: a Freudian slip!
Post reply on HN