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

Professional Corner-Cutting (2016)

blog.ometer.com

Post reply on HN
Print view View original

51–60 of 142 posts

Re: Professional Corner-Cutting (2016)

#51

Post by YZF »

justin_oaks wrote: post #20

> If the technical debt is a problem, 1) we shouldn’t have put it in there, and 2) we should include it in our estimates and address it. Yes. Don't tell your boss that you'll need to take time to address technical debt. The boss will always say "No don't do that, just add the feature". Sometimes they add "We'll fix that later." Later never happens and eliminating related technical debt is part of implementing the fea…

This is not the right answer for a real business. Sometimes we'll fix that later is perfectly acceptable. If that was good enough for Facebook it can certainly be good enough for others.

Re: Professional Corner-Cutting (2016)

#52

Post by maerF0x0 »

> A professional developer does thorough work when it matters, and cuts irrelevant corners that aren’t worth wasting time on. Extremely productive developers don’t have supernatural coding skills; their secret is to write only the code that matters.

IMO the true mark of a professional, a truly talented, engineer is knowing which corners to round off before they cut you. Anyone can cut corners and leave the world full of problems for the next guy. But then the assumptions change. A queue gets really full, or we start needing utf-8 for emojis, or someone wants to rearrage the field order in a CSV.

A great engineer would make a system that just works in those cases, because they can be (at least in go, node, python) implemented in just as many lines, just as complex of code, the only thing required is foresight (or its cousin, experience). Many will say YAGNI, but in my experience these things almost always come up (and I'm sure there are many others). Sometimes being a great engineer means reading between the lines of product designs, past sevs, and experience to figure out what the real feature ought to be.

Re: Professional Corner-Cutting (2016)

#53

Post by maerF0x0 »

renewiltord wrote: post #34

“Any fool can build a bridge that stands. It takes an engineer to build a bridge that barely stands”. Absent trade-offs I can do anything.

or as I like to tell my product folks "I can build you anything a computer can do, but you might not like the cost"

Re: Professional Corner-Cutting (2016)

#54

Post by jxl62 »

The ideas aren't as universal as they are made out to be. "Technical tradeoffs" are often not just technical, but also a business decision. They can have significantly different risks, costs and implications for business strategy. You may not have the insight into these things like someone who makes it their job. The "tenons" comparison frames these decisions as being trivial details that happen in a vaccum which smells like strawman. There are generally more factors to consider in tech decisions, and unlike cabinetry there is often a great deal of uncertainty in how it will play out in the future. This advice could be reasonable in the right company and role, while completely setting someone up for failure in another. There's irony in the article being about corner cutting and tunnel vision.

Re: Professional Corner-Cutting (2016)

#55

Post by afro88 »

> If the technical debt is a problem, 1) we shouldn’t have put it in there

I guess it depends on your definition of tech debt, but there are lots of examples of things that aren't tech debt at the time but become tech debt over time. You can make the best decision possible today, but in six months that npm dependency (for example) is still going to be incompatible with that other npm dependency you needed to upgrade, and you need a few days to figure it out.

A cabinet maker might not put "make tenons straight" in a sprint, they would include it in the estimate and not tell the customer, sure. But they would definitely tell the customer that their lathe tool broke and they needed a few days for repair before continuing work.

Re: Professional Corner-Cutting (2016)

#56

Post by skydhash »

jack_h wrote: post #44

I'm going to have to disagree with the entire premise of this piece. If you are a cabinet maker you have many individual clients who all want what you're producing. They each have their own budget and preferences that you can work with to get them something they want to buy. The incentives and constraints are clear here. If you can make something the client wants at a price and quality point they can afford you will…

What I've seen mostly is developers bringing complexity, then cutting corners after that because they don't want to deal with it. In Coders at work, Douglas Crockford said to spend the sixth cycle - whatever the cycle is - on refactoring. It's a sound advice if you care about technical debt as an engineer. Spend some time to revisit the code architecture to see if it still fits the problem you're solving. Instead of spending three cycles on something that could have been done in one because of how fragile everything is. Or having a long list that is tied to the same root cause.

Sometimes it means redo your React marketing website in Node and EJS (or the equivalent) instead of trying to make it SSR too.

Re: Professional Corner-Cutting (2016)

#57

Post by speed_spread »

YZF wrote: post #51
justin_oaks wrote: post #20

> If the technical debt is a problem, 1) we shouldn’t have put it in there, and 2) we should include it in our estimates and address it. Yes. Don't tell your boss that you'll need to take time to address technical debt. The boss will always say "No don't do that, just add the feature". Sometimes they add "We'll fix that later." Later never happens and eliminating related technical debt is part of implementing the fea…

This is not the right answer for a real business. Sometimes we'll fix that later is perfectly acceptable. If that was good enough for Facebook it can certainly be good enough for others.

Its up to the engineers to factor in maintenance work as part of their estimates. Business people assume perfect software and react badly when confronted with the messiness of software development.

Also, Facebook being a real business is questionable.

Re: Professional Corner-Cutting (2016)

#58

Post by skydhash »

afro88 wrote: post #55

> If the technical debt is a problem, 1) we shouldn’t have put it in there I guess it depends on your definition of tech debt, but there are lots of examples of things that aren't tech debt at the time but become tech debt over time. You can make the best decision possible today, but in six months that npm dependency (for example) is still going to be incompatible with that other npm dependency you needed to upgrade,…

> You can make the best decision possible today, but in six months that npm dependency (for example) is still going to be incompatible with that other npm dependency

This is a solved problem. You either understand the dependency enough to maintain it yourself, or you firewall it through interfaces. Or you tie yourself to sensible projects that gives you time for upgrade. Or you pay for support. Every decision should be taken with a complete understanding of pros and cons, and risk management to reduce the latter.

This cabinet make should either have a backup tool or be confident they can do the repair in a way that doesn't impact their consumer.

Re: Professional Corner-Cutting (2016)

#59

Post by paulryanrogers »

brandall10 wrote: post #12
sillysaurusx wrote: post #2

Am I hallucinating, or does anyone remember the Steve Jobs story as the exact opposite? He used backs of a cabinet as an example of when it’s okay to cut corners, since nobody would ever see it. I don’t remember where I heard it or what the context was, but it was something along the lines of him trying to get one of the early Mac engineers to ship faster. There was a lot of corner cutting to get the original iPhone…

I think that's two very different things - a complete set of features done poorly vs. an incomplete set of features done well. In general it's best to err on the side of the latter, it's going to give the customer a better UX. What exactly was the original iPhone missing? The only thing in the OS I recall was copy/paste. The other things we'd take for granted today likely weren't conceived then, including the App Sto…

> The other things we'd take for granted today likely weren't conceived then, including the App Store.

IIRC, one could get apps on other platforms like Blackberry, even over the web. Apple's anti-innovation was a closed-garden storefront.

Re: Professional Corner-Cutting (2016)

#60

Post by gofreddygo »

dkarl wrote: post #32

The hook of the article leaves unanswered the question of why Steve Jobs made a big deal out of the backs of cabinets. The answer is that Steve Jobs knew how to sell luxury items to people who identified themselves with the quality of their work, whether they were accomplished creative professionals or cube-dwelling (now coworking) "knowledge workers" or MBAs who take sommelier classes or aspiring writers grinding on…

Article is spot about its topic - tradeoffs. The professionalism is in picking the right corners to cut.

Steve's marketing was IMO a whole load of bollocks, like all other marketing. it gets attention now when Apple is a trillion $$$ company, and superficial minds wanting a simple answer attribute it to the most visible thing - Apple's marketing. no one bought Apple products for Apple's marketing or advertising. Its for the weirdos. Same theme as other Apple marketing e.g. the bicycle for the mind metaphor, the 1984 ad, etc.

This article is good and its not about the backs of cabinets.

Post reply on HN