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

How to build apps pragmatically

alextoussaint.com

Post reply on HN
Print view View original

11–20 of 51 posts

Re: How to build apps pragmatically

#11

Post by smoe »

SirensOfTitan wrote: post #9

More often than otherwise, I’ve found code duplication preferable over abstraction. I only abstract code when I understand the problem space really, really well (I.e. have solved it before), or when I can have some certainty the wrong abstraction won’t cost me too much time to fix.

Agreed.

Also one can get over-eager with abstractions over things that are not real duplicates. They just happen to look similar at this moment in time.

In this category, I would also put premature automation before learning what it actually is you are automating among other things.

Or more generally: Don't try to be clever about something you don't (yet) understand.

Re: How to build apps pragmatically

#12

Post by vbezhenar »

Some old tools are gold. It's good to know them. You can master regular expressions and they are applicable everywhere, from simple parsers to mass-editing the files. You can master UNIX shell and some tasks will be incredibly easy. You can master vi and you'll be able to edit remote files over terrible ssh connection.

Also, IMO, some old tools are not bad, even if they're out of fashion. I can write web application with Java Servlets and JSP like it's 2000 and it'll be fast and performant enough for many use-cases, not everyone have to use React. So if some tools are not that good, but you know them very well, may be it's worth to keep them around.

Re: How to build apps pragmatically

#13

Post by chubs »

smoe wrote: post #11
SirensOfTitan wrote: post #9

More often than otherwise, I’ve found code duplication preferable over abstraction. I only abstract code when I understand the problem space really, really well (I.e. have solved it before), or when I can have some certainty the wrong abstraction won’t cost me too much time to fix.

Agreed. Also one can get over-eager with abstractions over things that are not real duplicates. They just happen to look similar at this moment in time. In this category, I would also put premature automation before learning what it actually is you are automating among other things. Or more generally: Don't try to be clever about something you don't (yet) understand.

I once read a guideline (by DHH I think?) "One, Two, Refactor" as in write it once, then duplicate it, and the third time think about refactoring it to be DRY. But yes it's all about discerning what's reasonable given the circumstances, and not being dogmatic.

Re: How to build apps pragmatically

#14

Post by codr7 »

SirensOfTitan wrote: post #9

More often than otherwise, I’ve found code duplication preferable over abstraction. I only abstract code when I understand the problem space really, really well (I.e. have solved it before), or when I can have some certainty the wrong abstraction won’t cost me too much time to fix.

It takes time to build the kind of self confidence and humility it takes to allow a code base to sprawl for a while until you've seen enough examples to have an idea where it's going.

The first thing I like to do is solve the problem, period. Without inventing anything, just simply write code to cover most cases. Then I'll start improving on it in small ways, cutting down on duplication and inventing abstractions; until I reach a tipping point where I can visualize a complete design, which results in a major refactoring.

It looks messy in comparison to so called best practices, but it's faster and the code that comes out of the process is clearly better.

DRY is hurting more than helping if you ask me; because it shames inexperienced developers into premature abstraction, causing plenty of pain and misery along the way.

Re: How to build apps pragmatically

#16

Post by jakelazaroff »

"Use Popular Tools", "Old Doesn't Mean Gold" and "Use The Right Tool" are all kind of contradictory. "Cool" and "popular" are usually correlated. "Old" might correlate inversely with "cool" but directly with the ease of finding plugins, Stack Overflow issues and blog posts.

IMO, the criteria to use when evaluating a tool are 1) cost of building it yourself, 2) how well you know the tool, 3) how big the community is, and 4) how well the tool fits the job.

Re: How to build apps pragmatically

#18

Post by afarrell »

jakelazaroff wrote: post #16

"Use Popular Tools", "Old Doesn't Mean Gold" and "Use The Right Tool" are all kind of contradictory. "Cool" and "popular" are usually correlated. "Old" might correlate inversely with "cool" but directly with the ease of finding plugins, Stack Overflow issues and blog posts. IMO, the criteria to use when evaluating a tool are 1) cost of building it yourself, 2) how well you know the tool, 3) how big the community is,…

> "Use Popular Tools", "Old Doesn't Mean Gold" and "Use The Right Tool" are all kind of contradictory.

Yes, but that doesn't make them simultaneously good advice. The tension among these three is one of the trichotomies of technical leadership.

Re: How to build apps pragmatically

#19

Post by arexxbifs »

> Try to build a complex server-rendered web app with PHP because "It's more inclusive" or "it has better frontend performance". See you in 2030.

Like Facebook, WordPress and MediaWiki? Bashing PHP is a popular pastime, but front-end performance and inclusion are not to be scoffed at. Especially not if your target audience has a different standard of living than that of a major European city.

Personally, I'm much more worried about optimizing heavily third-party dependent front-end code to perform well on old laptops and cheap phones than I am with scaling up and load balancing a server-rendered site.

Post reply on HN