Ask HN: What did you learn the hard way? • Hacker News Board

Re: Ask HN: What did you learn the hard way?

#221

Post by skate22 » Wed, Oct 03, 2018, 9:03 PM UTC

your-nanny wrote: post #202

jonesdow wrote: post #171

Earlier quoted context omitted.

Speaking of dishwashing and life lessons. When I was in college (20 years ago) and sharing an apartment with 3 colleagues, the guys were leaving their dishes unwashed in the kitchen sink. Initially I washed my own dishes after finising a meal, only to find out the colleagues happily used my clean dishes then let them dirty in the sink. I realized I'm washing them twice: once when picking them dirty from the sink, was…

no but you can do like the Romans and break all their plates.

I just kept mine in my room

Re: Ask HN: What did you learn the hard way?

#222

Post by bachbach » Wed, Oct 03, 2018, 9:05 PM UTC

java-man wrote: post #89

jackconnor wrote: post #49

Accept all negative criticism advice as well as you possibly can. If it's just someone being an asshole it's very easy to know that and just ignore, but if it's real it's the most valuable feedback you can get.

This is not going to go well in the US or the British culture...

Think this is one of the universals. It's not that we're good at it - it's that there exist other cultures worse still.

Re: Ask HN: What did you learn the hard way?

#223

Post by crb002 » Wed, Oct 03, 2018, 9:07 PM UTC

Chesapeake Bay is not in a costal county list of hurricane zones because it isn't in a county.

Re: Ask HN: What did you learn the hard way?

#224

Post by Insanity » Wed, Oct 03, 2018, 9:07 PM UTC

balladeer wrote: post #213

kichik wrote: post #77

A company is a company, not a family. It's about making money, not about relationships. For better or worse, it's never really personal.

My late realisation (and at a cost) may be related to yours - your coworker is not your friend, better keep it that way.

Another related one: having friends become colleagues can be challenging.

Re: Ask HN: What did you learn the hard way?

#225

Post by discreteevent » Wed, Oct 03, 2018, 9:17 PM UTC

itsreallyme wrote: post #174

fhood wrote: post #75

Earlier quoted context omitted.

"Our code is self-documenting. If you need documentation then the code isn't written well enough" -Assholes who don't know what it is like to work with mature code bases.

"Our code is self-documenting. If you need documentation then the code isn't written well enough" -Assholes who don't know what it is like to work with mature code bases. - People who don't know how to write clean code

I hope you are using someone else to judge how clean your code is. (Maybe you are, maybe it is). I have come across very little self documenting code outside of a textbook. Code is a very low level medium. In the meantime a comment can help save a lot of time.

Re: Ask HN: What did you learn the hard way?

#226

Post by artificial » Wed, Oct 03, 2018, 9:20 PM UTC

peckrob wrote: post #65

artificial wrote: post #24

Always make backups. The little bit of time it takes will be a life saver if anything transpires unexpected. Oh and don't deploy on Fridays.

On this same note, test your backups occasionally. Untested backups are worse than no backups.

You're spot on! Specifically I was referring to SQL data. Been bitten more times than I'd like to admit making a hasty change.

Edit: refined.

Re: Ask HN: What did you learn the hard way?

#227

Post by alexcnwy » Wed, Oct 03, 2018, 9:28 PM UTC

smilesnd wrote: post #191

markdoubleyou wrote: post #122

If you're a dev, don't work for a company where software development is viewed as a cost center--you want your work to be viewed as something that brings in revenue. (Learned the hard way when I worked at a large bank.)

I agree with this full-heartedly I work for a company where my boss told me a couple months in having a dev department was a waste of money for the company, and we were lucky to have a job. The company bread and butter was software that transcribe medical records from paper to digital. What the CEO and sale force didn't tell anyone it was actually a cubical farm of humans transcribing it all since the software was ho…

Sounds awful! I've been working my butt off with some friends on a system to extract data out of scanned forms and documents (incl. handwriting) and I'd really appreciate hearing your thoughts about it. Couldn't find your contact deetz so please send me an email - address in my profile :)

Re: Ask HN: What did you learn the hard way?

#228

Post by jakobegger » Wed, Oct 03, 2018, 9:31 PM UTC

swagtricker wrote: post #195

itsreallyme wrote: post #174

Earlier quoted context omitted.

"Our code is self-documenting. If you need documentation then the code isn't written well enough" -Assholes who don't know what it is like to work with mature code bases. - People who don't know how to write clean code

Sorry, parent poster: Gotta agree w/ above comment here. With the minor warning that the unit tests are included in this. In a good environment, I should be able to go to the tests to understand not only WHAT the code is doing but WHY it's doing it. No matter how 'mature' the code base is.

In any mature code, there is going to be unintuitive code that only exists to work around an external issue beyond your control.

Recent example: when you authenticate to OpenSSH running on macOS 10.13 or 10.14, make sure to never attempt keyboard-interactive auth after password auth, or the server will stop responding.

Somewhere you need to write this fact down, so that the next person who comes across your auth code doesn't change the order of authentication methods.

You need to document things like that.

If you have a mature code base, you'll have dozens, or hundreds of these workarounds for all kinds of issues. If you look at the code, it'll seem inefficient. If you don't document why the code looks like it does, then someone will come along (possibly you) a few years in the future and "optimise" that line.

Sure, you could have a unit test that checks whether the workaround is in place. But then you STILL need to document why that unit test is there, or someone will come and consider it pointless and remove it.

Re: Ask HN: What did you learn the hard way?

#229

Post by bitfhacker » Wed, Oct 03, 2018, 9:33 PM UTC

bunderbunder wrote: post #214

bitfhacker wrote: post #199

Earlier quoted context omitted.

> Or, to put it a bit more optimistically - usable now is better than perfect later. This is the same principle of Minimum Viable Product. In MVP you launch the first version of your product with sufficient features, but not all, to early adopters so that you can get feedback from them. MVP and the "Build Measure Learn" feedback loop, gives you important tools to leverage your product.

Yes, absolutely. The language around MVPs tends to be couched in terms that pretty directly implies designing a product for external customers, though, so it tends to be harder to internalize for people who are doing in-house work, and even people who are somewhat removed from the product design process, such as many junior developers. What I've seen in is that it's common for people who are eager to impress their cl…

> The magic insight for me was when I finally realized that I could give people less than what they asked for, and they'd actually be happier than if I tried to give them everything they wanted.

I consider that a form of art/skill that we learn through multiple experiences (and errors too).

I work closely with developers and I observed that the majority try to implement always the perfect solution that normally comes with a high cost and time to develop. Clients normally prefer a solution that is quicker to implement but that responds to 80% of what he wants.

Re: Ask HN: What did you learn the hard way?

#230

Post by jackthetab » Wed, Oct 03, 2018, 9:47 PM UTC

dver wrote: post #72

artificial wrote: post #24

Always make backups. The little bit of time it takes will be a life saver if anything transpires unexpected. Oh and don't deploy on Fridays.

Added corollary, Always test restore your backup, it's the best example of schrodinger's cat.

I never liked the "be sure to make backups" and have "and be sure to test" as an afterthought (or "added corollary" in this case :-). Most ppl ignore the afterthought.

I taught my students "You don't need a backup system. You need a _restore_ system." It changes the mindset from "Yes, we make backups every night" to "Yes, we can restore the database in x hours".

I've seen way too many companies take the "we're good; we make backups" only to fail when trying to restore.