Things I Wish I’d Learned Sooner After Being a Developer for 10 Years • Hacker News Board

Re: Things I Wish I’d Learned Sooner After Being a Developer for 10 Years

#61

Post by fiddlerwoaroof » Sat, Nov 21, 2020, 7:05 PM UTC

kazinator wrote: post #42

fiddlerwoaroof wrote: post #21

Earlier quoted context omitted.

Part of the problem with things like "implement Bubble Sort" is that most actual programming tasks are "here's a problem, find the best implementation". There aren't many sorting tasks where Bubble Sort is an appropriate implementation: a _better_ interview question would be "here's a list of numbers, sort them without using a standard library function." Followed by "what are some advantages/disadvantages of the meth…

FizzBuzz also has zero practical value, yet it will filter out people who can't code.

But, the question is formulated like a normal programming task: it's not "implement this algorithm" it's "come up with a program that removes numbers that meet this specification".

Re: Things I Wish I’d Learned Sooner After Being a Developer for 10 Years

#62

Post by quentinp » Sat, Nov 21, 2020, 7:06 PM UTC

soneca wrote: post #8

Off-topic comment: I was having some trouble understanding the text. The author would start explaining some advice and I didn’t know which advice he was referring to. Like ”This is one I struggle with the most” , “this” what? I would go back to the previous paragraph and there was no reference, worst, apparently it was another topic! Then it hit me, the images with words on it every few paragraphs were the pieces of…

This is called the banner blindness effect: https://en.wikipedia.org/wiki/Banner_blindness

Re: Things I Wish I’d Learned Sooner After Being a Developer for 10 Years

#63

Post by ajarmst » Sat, Nov 21, 2020, 7:10 PM UTC

aiisjustanif wrote: post #51

ajarmst wrote: post #32

Earlier quoted context omitted.

An aphorism I occasionally use (I can be tedious): "the only way to make a twenty-year old comfortable leading a meeting is to wait until they're a thirty-year old." Doesn't stop us from forcing the poor bastards to do public-speaking assignments or dropping them into "teams" of completely inexperienced people they've never met with no leaders in the name of ephemeral "soft-skills."

This is such a self-fulfilling prophecy it hurts. Especially having been in leadership programs with other engineers in my early 20’s and go on to see them have some of the best soft skills in my later years. After 3 Fortune 100 companies, I have met a magnitude more of software engineers and infrastructure engineers over 40 that refuse to speak up and refuse lead because they see same thing over and over again, new…

The numbers are arbitrary. My primary point is that many important skills cannot be learned without the requisite experience. Individual experiences, talents and interests vary. Perhaps adjust my crude analogy to note that your very good manager at 28 would probably agree that she wasn't very good at it when she first left school or for the first few years of her career, and that her skill at working with other people was learned primarily from working with other people, not self-study, instruction, or other process that allowed for much compression of the time it takes. Those who excel early usually have done so because they started earlier and sought more opportunities for the necessary experience. I suspect if you broke it down to hours, you'd find a similar number, just applied at a rate of 20 hours a week instead of 10.

Re: Things I Wish I’d Learned Sooner After Being a Developer for 10 Years

#64

Post by forinti » Sat, Nov 21, 2020, 7:12 PM UTC

LeifCarrotson wrote: post #38

Regarding "Learning to say no", I agree that's an under-emphasized skill. Too often, the answer I give when asked "Could the software be made to do X?" is "Yes, it could, but no, it should not." The exported data is in CSV. Excel can import it. Yes, I could import an Office library and write XLSX files natively, but while the person making the request screwed up by making the wrong selection after marking up the data…

Even if you know how to say no, there are probably a few people up the chain who are paid to say yes.

Re: Things I Wish I’d Learned Sooner After Being a Developer for 10 Years

#65

Post by khendron » Sat, Nov 21, 2020, 7:13 PM UTC

I would reword "Vote with you feet" to be "It's OK to change jobs", so as to give it a broader meaning.

There is no obligation for you to stay in a job you don't like, or to pursue a different opportunity. You don't have to explain your reasons for leaving. Your employer and your team will probably be fine without you, and if they are not it is not your problem. To often I've stayed in a job I didn't like because "I'd be letting my team down" or "we're too busy, now is not a good time." Screw that. If you are not liking it, find something else and leave.

I'd also add one more: "Take your vacation". You are no good to anybody (you, your friends, your family, or your employer) if you work self to burn out. It's not worth it, and the world won't end while you are away.

Re: Things I Wish I’d Learned Sooner After Being a Developer for 10 Years

#66

Post by deckard1 » Sat, Nov 21, 2020, 7:16 PM UTC

leetcrew wrote: post #23

mewpmewp2 wrote: post #7

Earlier quoted context omitted.

I forget what I don't use. Should I rememorize those things every 6 months?

99% of the data structure decisions I make at work are whether I should use a vector, a tree, a hashmap, or (very rarely) a list. the standard library implementation of whatever I choose is almost always sufficient. I wouldn't expect the average programmer to be able to implement all of these on the spot, but if you don't use them enough to understand the basic trade-offs, I have to wonder wtf you are doing all day?

Even if you know the broad strokes, asking the average developer to implement most data structures will be a disaster. I'm reminded of the fact that most binary search algorithms are badly broken:

> When Jon Bentley assigned binary search as a problem in a course for professional programmers, he found that ninety percent failed to provide a correct solution after several hours of working on it, mainly because the incorrect implementations failed to run or returned a wrong answer in rare edge cases. A study published in 1988 shows that accurate code for it is only found in five out of twenty textbooks. Furthermore, Bentley's own implementation of binary search, published in his 1986 book Programming Pearls, contained an overflow error that remained undetected for over twenty years. The Java programming language library implementation of binary search had the same overflow bug for more than nine years.

Knuth had this to say:

> Although the basic idea of binary search is comparatively straightforward, the details can be surprisingly tricky

https://en.wikipedia.org/wiki/Binary_search_algorithm#Implem...

If the experts can't get it right, no developer in an interview setting has a chance. It's a game of "gotcha." The interviewer has some trick that they are privy to and are waiting for the interviewee to mess up and... GOTCHA! You got it wrong, it's this clever trick that you would have to know ahead of time! Silly person thinking they can get a job here without knowing the secret handshake.

Re: Things I Wish I’d Learned Sooner After Being a Developer for 10 Years

#67

Post by scarmig » Sat, Nov 21, 2020, 7:17 PM UTC

leshow wrote: post #53

scarmig wrote: post #49

Earlier quoted context omitted.

If you're working with rotating drum memory, bubble sort provides the best real world performance for any kind of data set that would fit on it.

Do I need to specify that I'm talking about modern computers? That's an interesting bit of trivia though.

I think it's a useful way to keep in mind that algorithmic complexity isn't everything in the real world, which also applies to today.

When would bubble sort be ideal? When it's relatively cheap to read data sequentially compared to backwards or randomly, and resetting to the initial read position isn't too costly.

Now I've nerd sniped myself, and am brainstorming how that situation might arise with modern systems...

Re: Things I Wish I’d Learned Sooner After Being a Developer for 10 Years

#68

Post by mgkimsal » Sat, Nov 21, 2020, 7:20 PM UTC

deckard1 wrote: post #57

mgkimsal wrote: post #26

Earlier quoted context omitted.

Had a colleague die a few years ago. He'd lost some project work, and let his life insurance lapse. Had a heart attack just a few weeks later, and left a wife and 3 kids with very little. He worked from home and spent time with them, but had hit a point where money was a problem. The story sticks with me because he'd contacted me just a couple months before he died asking if I had any work/referrals, and I had nothin…

> I'm actually amazed at how many folks work for decades, then something happens, and there's a gofundme set up for the family to help with day to day bills. Not to go all Bernie Sanders on you, but... welcome to America? Maybe you don't live in the US. But here in the US, a single medical bill can wipe you out. And because we value free market healthcare, that means you don't know what the price will be until after…

I do live in America, and possibly should have qualified that statement. The folks I was referring to were already ... middle class or higher, who understood the value of savings/insurance, and had ample opportunity to do so, and still didn't. That's what sort of... gets me. Situations where people were never earning enough to be able to remotely prepare for financial setbacks... I don't include them in my "amazement" comment. I'm generally "amazed" they manage to survive at all in today's world.

I've not quite had the situation you've mentioned with medical stuff, but have had some ER visits which end up costing thousands out of pocket on top of the ~$10k/year we spend on insurance.

For people I've known who were in software, or engineering, or law, and had high-paying careers over decades, to know they were still living that close to the edge financially, that's what amazes me. And sometimes it's bad spending habits (or drugs, or whatever), sometimes it's just poor financial education.

But to the original point - an extra ~10% year in income to many folks - even if it means a slightly reduced 'quality of life' by some measure - can have an impact on their lives down the road, but they also need to manage that extra income properly.

Re: Things I Wish I’d Learned Sooner After Being a Developer for 10 Years

#69

Post by ajarmst » Sat, Nov 21, 2020, 7:25 PM UTC

vvanders wrote: post #37

ajarmst wrote: post #9

An observation: a lot of these---especially 'soft skills'---can't be properly learned earlier. They're a side effect of experience, and the 10 years doing the job is the only way to properly get them. The things I most often hear from potential employers when we ask what we should focus on more in teaching them are "soft skills" and "troubleshooting". My response is now to ask which of the long list of technical skil…

I would add that part of that experience is seeing how teams/situations/products pan out and then being able to recognize those patterns and nudge/head off issues early in the process. In that respect I've learned a lot more from projects that have gone off the rails to some degree than projects where everything went according to plan. In an ideal world you have the opportunity to give each person on the team the rig…

Failure is our best teacher. I do spend a lot of time on that with my students. I have a professional and personal interest in formal failure analysis, and try to instill that in students. Apollo 1 saved more lives than it took, and Windows Vista teaches you everything you need to know about monolithic, slow-moving software projects with unclear goals. Dai-Katana and Duke Nukem are masters' courses in the toxic interaction of aggressive marketing and product development. I think Trump might end up being one of the best things that ever happened to American Democracy.

Re: Things I Wish I’d Learned Sooner After Being a Developer for 10 Years

#70

Post by aliceryhl » Sat, Nov 21, 2020, 7:27 PM UTC

mewpmewp2 wrote: post #7

bjornjajayaja wrote: post #5

I tend to disagree with many of the sentiments. In particular, many software folks don’t know the most rudimentary data structures and algorithms. Those should be memorized, frankly. Lately I have been exploring old programming books on archive.org and realize how downhill the industry has gone from fundamental principles, which leads to “language-z” zealots to satisfy some business need. The author mentions COBOL as…

I forget what I don't use. Should I rememorize those things every 6 months?

I'm also one of those people who think people should know rudimentary data structures and algorithms, and the reason I think this is that they come up all the time!

Sure, you could get through the situations I'm thinking of without knowing anything about this, but if you don't think about it, you risk filling the code with lots of O(n^2) loops that could be O(n) if you added an extra map. This is how you end up with applications that are slow due to a thousand small cuts.

If you don't think about these things, then I can only assume that it's because you don't notice them when they come up.

To be clear, there's nothing wrong with choosing the slower implementation because its simpler. What's important is that you thought about the trade-off, and often the O(n) loop is not more complicated than the O(n^2) one.