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

Things I learnt the hard way in thirty years of software development

blog.juliobiason.net

Post reply on HN
Print view View original

211–220 of 308 posts

Re: Things I learnt the hard way in thirty years of software development

#211

Post by ChrisMarshallNY »

koonsolo wrote: post #59

Great lessons! Although it didn't include one that I had to learn the hard way, multiple times: Your throwaway prototype will be the codebase for the project. In my career, I've seen multiple throwaway prototypes that were hacked together. None of them ended up in the waste bin. "Just add X and Y and you're done". "But this is just a quick hack to show the interface, there is nothing behind it!" "Yes, and the interfa…

This is the reason I am less-than-thrilled with the way most companies get to MVP. Make MVP good quality ("V" should have "Quality" as a principal metric). It may be bare bones, but don't skimp on the quality. Or you'll be very, very sorry.

Re: Things I learnt the hard way in thirty years of software development

#212

Post by 1PlayerOne »

maxxxxx wrote: post #67

One thing I have learned in almost 30 years of SW development: work somewhere where the CEO has at least a basic idea of your work and sees value in your work, not just cost. Work somewhere where people care for the craft and it’s not only about “business” goals.

Can you give examples of companies that fit your description?

Re: Things I learnt the hard way in thirty years of software development

#213

Post by therufa »

> Data flows beat patterns (This is personal opinion) When you understand how the data must flow in your code, you'll end up with better code than if you applied a bunch of design patterns.

this one is priceless.. I had so many arguments in my past with cocky devs about this topic. Don't get me wrong, patterns are good, but it's only a small part of coding. Also patterns aren't there to follow them as they where the law, but bend them to your needs. One doesn't even necessary needs to be implemented to 100% as it is in the "book". So yes, this part of the post i'm very fond of, it's really wise.

Re: Things I learnt the hard way in thirty years of software development

#214

Post by [deleted] »

1PlayerOne wrote: post #212
maxxxxx wrote: post #67

One thing I have learned in almost 30 years of SW development: work somewhere where the CEO has at least a basic idea of your work and sees value in your work, not just cost. Work somewhere where people care for the craft and it’s not only about “business” goals.

Can you give examples of companies that fit your description?

[deleted]

Re: Things I learnt the hard way in thirty years of software development

#215

Post by lliamander »

> Also, remember that most people that are against CoCs are the ones that want to be able to call names on everyone.

There's a XKCD comic which points out how people who claim to "hate drama" tend to be the most dramatic people[1].

That's how I tend to perceive projects that put a lot of emphasis on their CoC. The more they emphasize it, the more I expect pettiness, vindictiveness, and bad faith.

[1]https://xkcd.com/1124/

Re: Things I learnt the hard way in thirty years of software development

#216

Post by pmarreck »

tomelders wrote: post #13
_asummers wrote: post #7

Earlier quoted context omitted.

> it’s a pretty long read... clearly the author did not learn brevity in his coding, or that his blog’s color scheme does not contribute to readability It's also riddled with typos which made reading it hard. There's some wisdom in there, but it was clearly written in an editor without spell/grammar checks. Maybe there should have been a section about rereading your own work before sending to your team/prod? =)

> Turn off comments

There should be a way to vet negative people in some way that comments wouldn't be toxic

Re: Things I learnt the hard way in thirty years of software development

#217

Post by jimpudar »

maxxxxx wrote: post #198
kstenerud wrote: post #57

One more point from my 20 years experience: Keep your development environment deterministic and instantly rebuildable. You should ideally be able to take your hard drive out, put in a new one, install a fresh OS, run 1 script, and be completely up and running in less than an hour. As an added bonus, this means that you can replicate your development environment on any machine very quickly and easily, which makes losi…

"You should ideally be able to take your hard drive out, put in a new one, install a fresh OS, run 1 script, and be completely up and running in less than an hour." this is great if you can pull it off but if you have a lot of disjointed systems plus maybe custom hardware it gets really hard to automate the process. In general I agree though. I also have learned to just live with the defaults of my IDE(s) instead of…

I keep all my Emacs config files in a git repository, so I can quickly pull it wherever I happen to be using Emacs. Might be practical for some IDEs too depending on their configuration file formats. I'd imagine it would work fine if the configuration is stored as XML.

Re: Things I learnt the hard way in thirty years of software development

#218

Post by travisjungroth »

lhuser123 wrote: post #139
koonsolo wrote: post #59

Great lessons! Although it didn't include one that I had to learn the hard way, multiple times: Your throwaway prototype will be the codebase for the project. In my career, I've seen multiple throwaway prototypes that were hacked together. None of them ended up in the waste bin. "Just add X and Y and you're done". "But this is just a quick hack to show the interface, there is nothing behind it!" "Yes, and the interfa…

Some researchers wanted a 128-bit space for the binary address, Cerf (recalled) ... But others said, "That's crazy," because it's far larger than necessary, and they suggested a much smaller space. Cerf finally settled on a 32-bit space that was incorporated into IPv4 and provided a respectable 4.3 billion separate addresses. "It's enough to do an experiment," he said. "The problem is the experiment never ended." htt…

IMO, they should have gone with a wildly smaller number. Enough IP addresses to get ~10% of the world online is just about the worst possible pick. It’s enough to get entrenched, but not enough to finish the job. If it was 1024, they would have run into the problem while it was easily fixable. Y2K wouldn’t have been a problem if two-digit years started being used in 1999.

Re: Things I learnt the hard way in thirty years of software development

#219

Post by pmarreck »

kstenerud wrote: post #57

One more point from my 20 years experience: Keep your development environment deterministic and instantly rebuildable. You should ideally be able to take your hard drive out, put in a new one, install a fresh OS, run 1 script, and be completely up and running in less than an hour. As an added bonus, this means that you can replicate your development environment on any machine very quickly and easily, which makes losi…

> All scripts are idempotent.

THANK YOU!

This is not a property that is exploited nearly enough!

Re: Things I learnt the hard way in thirty years of software development

#220

Post by mcv »

koonsolo wrote: post #59

Great lessons! Although it didn't include one that I had to learn the hard way, multiple times: Your throwaway prototype will be the codebase for the project. In my career, I've seen multiple throwaway prototypes that were hacked together. None of them ended up in the waste bin. "Just add X and Y and you're done". "But this is just a quick hack to show the interface, there is nothing behind it!" "Yes, and the interfa…

For this reason: write even your prototypes in a maintainable way. Don't go overboard, quick hacks are allowed where they save time (you might want to mark them with a // TODO), but even prototype code should be understandable.

Also: don't be afraid for dramatic refactoring. If you know it's necessary, do it. It will improve your code base immensely. And the earlier you do it, the easier it is.

And even when you do throw away your code, you're not going to throw away all of it. There are always bits that look good and work well, so you copy them into the new version.

Post reply on HN