Live data from Hacker News

Mastering Programming (2016)

tidyfirst.substack.com

101–110 of 123 posts

Re: Mastering Programming (2016)

#101

Earlier quoted context omitted.

> There's a ton of (as the kids say) alpha in each of the bullet points. Come on, I know I'm about to hit 40, but slang can't be evolving that fast! How am I supposed to be keeping up with all the kids?

Don't ask me! I don't have enough rizz to get included in those circles.

We became too complacent, and now we are paying the fanum tax (•́︿•̀)

Re: Mastering Programming (2016)

#102

Earlier quoted context omitted.

I have no horse in this race but I believe what the other poster was saying is that you might not need it but you should still think about it and decide if you should factor it into your designs. YAGNI creates problems.

Developers aren't great at sharing nomenclature, but by what seems to be the most common definition, YAGNI refers to not going off and implementing something that is more fun to implement, but isn't needed right away (if ever). Focus on what you actually need to get your project to a desirable state. It doesn't say you should not consider future considerations in your design. In fact, it suggests that you should desi…

YAGNI is more about design than implementation. It's about worrying about future concerns rather than what you know you need right now.

The truth is in the middle, sometimes you need to design for the future and sometimes you don't. Often designing for the future just means making sure you haven't designed yourself into a corner rather than being able to fully deal with the future but that's a nuance most people miss.

Re: Mastering Programming (2016)

#104
post #75

Earlier quoted context omitted.

I was trying not to make any judgement call, but I agree. To me there are worse things in the story, though: they tried to make User Stories and even customer-driven tests and ended up burning out the only customer that was able to do it. It's not only underwhelming compared to the silver bullet they were selling in conferences and books, but it required some unicorn customer that they couldn't replace. For years I s…

To me there are worse things in the story, though: they tried to make User Stories and even customer-driven tests and ended up burning out the only customer that was able to do it. This is still a legitimate concern today with the "product owner" role that a lot of popular Agile processes rely on. In effect the whole premise of having a PO embedded within the team as the authority on requirements that are expected to…

Definitely.

I think I draw the line at asking them to produce user stories, to me that's already too much. Asking them to use Cucumber or BDD rituals is probably against the Geneva convention.

There really is no silver bullet to writing software. You gotta keep a short feedback with users, and not overwhelming them is important.

Re: Mastering Programming (2016)

#106

> Isolation. If you only need to change a part of an element, extract that part so the whole subelement changes. I don't get what the author means by this. Anyone wants to elaborate?

Say some gigantic piece of function has 600 lines of code that does logic this, logic that and logic this and that. Suppose one day your PM goes into your office and request that a certain special case be added to this feature.

You do not further increase the complexity of this function by having one or two variables in the front, several if-elses in the middle not to mention a couple gotos.

You take these special cases and the most relevant logic away into yet another function, document it and hence ensure the changes to that 'special logic' do not mess up with the rest of that feature.

Re: Mastering Programming (2016)

#107

Earlier quoted context omitted.

Developers aren't great at sharing nomenclature, but by what seems to be the most common definition, YAGNI refers to not going off and implementing something that is more fun to implement, but isn't needed right away (if ever). Focus on what you actually need to get your project to a desirable state. It doesn't say you should not consider future considerations in your design. In fact, it suggests that you should desi…

YAGNI is more about design than implementation. It's about worrying about future concerns rather than what you know you need right now. The truth is in the middle, sometimes you need to design for the future and sometimes you don't. Often designing for the future just means making sure you haven't designed yourself into a corner rather than being able to fully deal with the future but that's a nuance most people miss…

> YAGNI is more about design than implementation

Not as it seems to be usually defined, but I agree that programmers are bad for not sharing a common nomenclature. We can't even agree what something as simple as enums are. So, no doubt that there are camps who hold that perspective. enterprise_cog clearly comes from the "don't implement", not "don't design" definition, though.

Re: Mastering Programming (2016)

#108

Earlier quoted context omitted.

YAGNI is more about design than implementation. It's about worrying about future concerns rather than what you know you need right now. The truth is in the middle, sometimes you need to design for the future and sometimes you don't. Often designing for the future just means making sure you haven't designed yourself into a corner rather than being able to fully deal with the future but that's a nuance most people miss…

> YAGNI is more about design than implementation Not as it seems to be usually defined, but I agree that programmers are bad for not sharing a common nomenclature. We can't even agree what something as simple as enums are. So, no doubt that there are camps who hold that perspective. enterprise_cog clearly comes from the "don't implement", not "don't design" definition, though.

"you aint gonna need it" can be clarified as "you aint gonna need all those extension points".

it can also mean you don't need functionality you're not using, including implementations for those extension points.

Re: Mastering Programming (2016)

#109

Earlier quoted context omitted.

> YAGNI is more about design than implementation Not as it seems to be usually defined, but I agree that programmers are bad for not sharing a common nomenclature. We can't even agree what something as simple as enums are. So, no doubt that there are camps who hold that perspective. enterprise_cog clearly comes from the "don't implement", not "don't design" definition, though.

"you aint gonna need it" can be clarified as "you aint gonna need all those extension points". it can also mean you don't need functionality you're not using, including implementations for those extension points.

While I accept your definition, because, hey, programmer's can't agree on definitions at the best of times, that is not the definition that was used earlier. And is not the definition presented by the XP gang.

John Carmack of Doom fame seems to share your definition, suggesting that attempts to plan architecture in advance will only come to bite you, but I'm not sure he is an XP subscriber and he certainly wasn't involved in C3.

Re: Mastering Programming (2016)

#110
post #76

Earlier quoted context omitted.

In the title of the post “- by Kent Beck”

How is that an appeal to authority?

Why submit it like that, but to indicate to readers why this article is worth reading? HN guidelines say to submit the title as is, without additional qualifiers or commentary. (Fortunately, the mods updated it)
Post reply on HN