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

Things I’ve learned in my 20 years as a software engineer

simplethread.com

Post reply on HN
Print view View original

611–620 of 745 posts

Re: Things I’ve learned in my 20 years as a software engineer

#611

Post by suzzer99 »

agumonkey wrote: post #549
chaps wrote: post #184

Earlier quoted context omitted.

I do a lot of dev work with non-profits and such. About a year ago I was working on an extremely difficult project as a volunteer where I was insistent that a specific part was vitally important to getting the project to move forward (generalizing tables extraction from scanned OCR docs) and I was spending a lot of time on it. One of the devs I worked with, with 40+ years of experience, basically told me this exact t…

minuscule anecdote: my most cherished lines of code were an 8 lines vba excel macro to count duplicates for a non tech colleague. Turned her day from hell to cool (she had to filter duplicates by hand and quadratic formulas over 2000+ lines spreadsheet. That's what computers are for.

I once spent two hours thinking about how to recursively assemble a tree structure from the database in a way that the JS presentation library wanted the data, then finally I wrote 2 lines of code.

Definitely my most cherished code.

Re: Things I’ve learned in my 20 years as a software engineer

#612

Post by 3grdlurker »

iammisc wrote: post #323
gavinray wrote: post #110

Earlier quoted context omitted.

Agreed, I don't know why the industry (or people?) in general have a problem with accepting this abilities gap. It's as if the notion of people being arbitrarily born more or less with a knack for something is evil. Let me tell you the story of when I realized I was (at best), a "not-mediocre" dev: 1. I've been programming for fun even as a kid. That's what got me into it: If you count kid-programming as "programming…

> It's as if the notion of people being arbitrarily born more or less with a knack for something is evil. The stretch from person A is a better programmer / SW engineer than B to 'thus, person A is innately better' is unnecessary. In my experience, the programmer that spends more time programming is almost always better than the one who does not. You can hate side projects, open-source work, whatever as much as you w…

I’m not sure if you described 10x people or one-track minds.

I love programming, I’m good at it, but what I do with my free time isn’t necessarily related to programming but is still definitely productive. I read up on economics, politics, maybe write a few essays or short stories, work out, pick up a new skill or something. Somehow being a holistic person is now considered mediocre?

Re: Things I’ve learned in my 20 years as a software engineer

#613

Post by steve_taylor »

12. People don’t really want innovation

People talk about innovation a whole lot, but what they are usually looking for is cheap wins and novelty. If you truly innovate, and change the way that people have to do things, expect mostly negative feedback. If you believe in what you’re doing, and know it will really improve things, then brace yourself for a long battle.

Ain’t that the truth. I’ve come up against this my entire career.

Re: Things I’ve learned in my 20 years as a software engineer

#614

Post by physicles »

marcus_holmes wrote: post #568
sangnoir wrote: post #421

Earlier quoted context omitted.

> Simplicity is an important design goal for all systems. Complexity breeds bugs Counterpoint: some problem-spaces are inherently complex; most problem-spaces have hidden complexity. Complexity cannot be removed , it can only be moved up or down your tech stack, and obviously, you can needless add more complexity. Docker, K8s and the like are perfectly fine when they fall below your project's complexity floor - they…

Totally agree. Some problems are complex. However, that does not mean that the code needs to be complex. Simplicity should still be a design goal even if the problem space is complex. I don't really agree that there is a "complexity floor". Things can always be made simpler, up to the limit of the problem space. As you say, complexity can always be added. Most projects do this. Very few stick to the minimum complexit…

> up to the limit of the problem space.

This is the key. One of the harder things to do in software design is to find a representation of the problem that gets closest to that complexity floor. It's often not obvious.

Re: Things I’ve learned in my 20 years as a software engineer

#615

Post by pksebben »

ninkendo wrote: post #129
boffinAudio wrote: post #25

Earlier quoted context omitted.

Even if YOU are the only user, you're still writing software for a human. Hopefully.

You’re writing software for all of your future selves. http://www.catb.org/~esr/writings/unix-koans/prodigy.html

Thank you for posting this. I feel understood.

Re: Things I’ve learned in my 20 years as a software engineer

#616

Post by zoomablemind »

hinkley wrote: post #427
ghaff wrote: post #398

Earlier quoted context omitted.

Yes, but it also doesn't give any indication of norms around the amount of time off people take. Expectations may differ from how much time is in a traditional PTO bank but at least in general, it's OK to take accrued time off barring special circumstances.

I worked at a place that gave us 2 weeks and then took an act of Congress and months of social engineering to take even a day. We got bought out and the new overlords announced they were going to give us five weeks of vacation. There was actual laughter in the room. We can't even use 2 weeks, what's 5 gonna do for us?

Wonder what did you guys produce that required all hands on deck at all time non-stop?

Re: Things I’ve learned in my 20 years as a software engineer

#617

Post by slyall »

adrianmonk wrote: post #544
bluGill wrote: post #502

Earlier quoted context omitted.

At my company you get one interview, if you get a second interview it is because we liked you but someone else was better and passed your resume on to a different team. One thing we do is take every candidate to lunch (COVID has changed this of course) with someone who doesn't have input into if you are hired: so feel free to ask those questions that you are not sure about. Having done a few interviews, nobody knows…

> lunch ... with someone who doesn't have input I think part of this could be that they don't know whether to believe that you truly have no input. When I was an interviewee, my lunch escort told me they didn't, and I was pretty sure it wasn't a devious trick to get me to let my guard down, but I had no way of knowing for sure. I also thought, if there isn't a formal process, maybe if I say something too dumb or wron…

Even if they have "no input", if the interviewee did or said something really extreme it would be reported back.

Re: Things I’ve learned in my 20 years as a software engineer

#619

Post by [deleted] »

Shaanie wrote: post #452
dosethree wrote: post #242

Earlier quoted context omitted.

If there are 10x engineers, it's a right place, right time situation. Very good engineers with the right experience, luck, a good idea, and the relentless desire to execute. Miss any of those things, and you can still be a a multiplier, just probably not 10x. Even so at my companies the difference between between good engineers and bad is massive (a lot of the difference is talent and motivation). Imagine you had a c…

There's honestly quite a few developers that produce zero or negative value (e.g. by implementing the wrong things, introducing lots of bugs or significant complexity etc). 10x:ing them is not difficult.

[deleted]

Re: Things I’ve learned in my 20 years as a software engineer

#620

Post by jstrong »

diamondo25 wrote: post #596
alerighi wrote: post #506

Earlier quoted context omitted.

No. It's like saying that a good mechanic can fix a car 10 times faster than another. Even if a good mechanic manages to find the problem in less time than a non experienced one, he still has to do the repair. That is similar to programming: even if you have everything clear in your head, you know how to do every single thing that is written in the requirements of the program, you still have to type it out. A lot of…

IMO having a fancier keyboard that does more clickety-clack will not make you a better programmer. If anything, your co-workers cannot work as good and will have to put more energy to focus. Experience and the skill to remember or recall well, help a lot with engineering.

sorry - you'll have to pry my model m from my cold, dead fingers
Post reply on HN