Things I’ve learned in my 20 years as a software engineer • Hacker News Board

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

#231

Post by randomsearch » Fri, Oct 08, 2021, 2:25 PM UTC

knorker wrote: post #141

randomsearch wrote: post #83

Earlier quoted context omitted.

To pose it another way: for general software Dev (not some niche use case that only one guy understands), let’s say building websites in Vue or React, the idea of a 10x developer is that they can work in January and another, average, programmer can then spend February, March, April, May, June, July, August, and Sept… and the average guy won’t get more done? Or they come in only every other Monday and contribute as mu…

How long would it have taken you or me to write Doom, or Quake? How long would it have taken Carmack, if it'd just been him? I think you have a false dichotomy here. Carmack isn't 10x better a C or assembly than me. But in his domain he's easily 10x smarter and more productive than me. And on top of that, he has a quarter century more experience in graphics programming than me. That shit accumulates. Yes, actually. I…

> How long would it have taken you or me to write Doom, or Quake? How long would it have taken Carmack, if it'd just been him?

I'm not a games programmer. I doubt a median games programmer would take 10x the length of time that it would take any other games programmer. It just seems implausible, and I don't know why people want to defend it.

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

#232

Post by Zababa » Fri, Oct 08, 2021, 2:25 PM UTC

Buttons840 wrote: post #205

> 4. The best code is no code, or code you don’t have to maintain > 17. Keep your processes as lean as possible > 20. Always strive to build a smaller system He stops just short of saying it, but IMO a program with fewer lines of code is almost always better. You can write your Java in Python and have it be 1/5th the lines. You can drop the classes and use functions and save some lines. Exceptions to this rule only h…

I think that's because non-generated lines of code are a form of "incompressible human work". Sure, one person can write twice as much lines as another. Even 10! But when you have a codebase of 10 millions lines of code, this is going to take a certain amount of man-years, and there is no way to reduce that. This is in stark contrast to the programs we write, that can replace large quantities of human work easily.

Some other ways of looking at this: compilers are an impressive force multiplier. When you compare the size of the source and the size of the executable, it's easy to see how much work you avoid. Compilers allow one single person to create way bigger programs. That would also explain why some people are so insistent on Lisp: macros are compilers. If you can write your own compiler, you can increase even more your own productivity.

This raises the question of why not everyone uses Lisp. The answer is collaboration. Collaboration happens when people share a mental model of things. The bigger the language, the harder it is to find lots of people that share that entire mental model. This may be why you often hear programmers with a lot of experience that prefer "small and simple" things, like C or Go. It makes collaboration easier. Dynamic vs static typing might be the same. It's about "how much context you need in your head at all time". If you have a lot of context in your head, it's easy to think about things succinctly. But when people don't have the same context as you or you lose yours, understanding their short and full of context code might be very hard. Spaghetti programs are that, a mix of context. You can't take one spaghetti out. You have the same exact problem in parsing, context-free vs context-sensitive grammar.

I don't know if and how the context-free vs context-sensitive ideas translate in terms of people. If anyone really likes using Lisp or Go or Haskell, I would be interested in your opinion about my "theory", and if you think that preference for context-free or context-sensitive applies to other parts of your life or personality.

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

#233

Post by d23 » Fri, Oct 08, 2021, 2:27 PM UTC

scottious wrote: post #107

> I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all. I've been a developer for 15 years... anybody else feel like the further they get into their career, the more they want to keep their opinions to themselves? I feel like as a junior dev I had way stronger opinions and I was a lot more vocal about them. Now, I still have opinions, but I've learned that nobody…

I pick my battles pretty judiciously these days. I've learned that a huge amount of what people talk about doing ends up going nowhere anyway, so why burn the energy and look disagreeable? A lot of people with bad ideas also aren't very good at getting things done.

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

#234

Post by taf21 » Fri, Oct 08, 2021, 2:28 PM UTC

moonchrome wrote: post #82

naruvimama wrote: post #37

> 11. ..... > Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software. The more you learn the more you realise you were wrong. Having an opinion has often come to mean one is a fan boy of something and will have it no other way. I have heard team leads say "this python code is bad because it uses no classes" or "we need to use EMR so we can process all cu…

The more I learn the more I realise everyone else is wrong too. Especially when it comes to general purpose tools - there's so many tradeoffs even in an ideal world but really often the original author just did things wrong, but right enough that his solution stuck and everyone kept piling on and building on top. PHP and node come to mind immediately. Ruby is down right retarded with promoting Concerns for modeling c…

Was the slur super necessary to make your point?

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

#235

Post by pjc50 » Fri, Oct 08, 2021, 2:29 PM UTC

mosburger wrote: post #85

pjc50 wrote: post #6

This is a very insightful list. But there is one thing I'd quibble with: while it's inherently a super-subjective metric, I would say that 10x programmers do exist. Both in the "can support a company by themselves" sense and the "mad lone genius" sense. Not all the 10x programmers are good at working with other people or on other people's ideas. 0.1x programmers are often lost or afraid, although they may just be uni…

I like to say that I am a 10x developer 10% of the time. My work tends to be very "bursty" followed by long bouts of low productivity. It probably has more to do with my mental health than anything else. :/

My personal joke about this is "I used to be a 10x developer but then I took an arrow to the knee".

Many, many years ago a colleague wrote about the experience of being bipolar and choosing to stop taking the lithium for a temporary productivity boost and subsequent crash.

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

#236

Post by faizshah » Fri, Oct 08, 2021, 2:31 PM UTC

quadcore wrote: post #96

The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly. You know, 10x is an optimistic number here. Some programmers will do in 1 day what you wont achieve in a life time. And not understanding that makes you a bad programmer by my book simply because this is the foundation of the job. So let…

This is the opposite of how you should want any knowledge worker to think. If you believe that there’s some innate ability that makes people 10x better at a skill than you rather than hours of practice and study then you are much less likely to acquire that skill or learn those skills efficiently. You need to have a growth mindset to be an effective knowledge worker not a fixed mindset.

This is discussed in the book Make It Stick on learning science, in chapter 7 they discuss how your own views on whether skill is innate vs the result of practice affects your own ability to learn and grow.

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

#237

Post by inglor » Fri, Oct 08, 2021, 2:32 PM UTC

darthvoldemort wrote: post #217

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…

If you're volunteering, why shouldn't you work on projects that you find interesting? I don't understand the point of view of the older dev.

I've found that volunteer work is _harder_ in terms of getting the human aspect right.

New volunteers sometimes expect the red-carpet treatment as someone volunteering their (pretty expensive presumably!) time and as someone accomplished in their field. Volunteers usually get the opposite treatment since it turns out the other volunteers tend to come from a similar perspective and someone doing the hard human work is often contributing a lot more to the project than an otherwise excellent engineer.

You can of course choose your volunteer activities to be interesting to you. Open source is one such very fun activity but lo-and-behold in projects I've been involved with the human aspect is often very important and requires a similar amount of hard work. This is often truer for bigger projects/organizations than small ones.

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

#238

Post by pjc50 » Fri, Oct 08, 2021, 2:33 PM UTC

bogwog wrote: post #215

Aaargh20318 wrote: post #172

Earlier quoted context omitted.

> The benefit of talented engineers comes from the fact that they avoid costly pitfalls - not that they pump out more code per hour worked. Not just avoid pitfalls, being able to put together a good architecture is a huge factor as well. The effect is cumulative. If you have a good design to begin with, everything becomes easier with less risk of bugs. The result is that implementing new, or changing existing functio…

> (s)he will probably write less code than the 1x developer. Or better yet, remove code.

https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

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

#239

Post by PragmaticPulp » Fri, Oct 08, 2021, 2:34 PM UTC

scottious wrote: post #107

> I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all. I've been a developer for 15 years... anybody else feel like the further they get into their career, the more they want to keep their opinions to themselves? I feel like as a junior dev I had way stronger opinions and I was a lot more vocal about them. Now, I still have opinions, but I've learned that nobody…

Having opinions is good, but only if they’re genuinely informed opinions and everyone is willing to disagree and commit.

I’ve worked with too many people who think that their opinions are their identity and defended them as such. A difference of opinions shouldn’t become an excuse to go to war with your coworkers or argue endlessly instead of getting things done.

One of my worst work experiences was with a team of developers who were old friends from a college debate team. We could never have any productive discussions because they entered every conversation intent on winning instead of having an honest, productive conversation.

The best engineers I’ve worked with have had strong opinions but have also been happy and willing to go a different way if that’s what the team decides as a whole.

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

#240

Post by jb3689 » Fri, Oct 08, 2021, 2:35 PM UTC

sporedro wrote: post #213

I feel like once you’ve worked on a few projects the desire to “reinvent” the wheel is quickly destroyed. The main thing they never teach in school and you really can’t understand until your doing it is maintenance. Projects are like a balancing act where you need to weigh the pros and cons of every choice and choose the best one. The hard part is being able to do that and do it in a reasonable amount of time.

The difference between a senior engineer and a junior engineer to me is that a senior engineer knows how to evolve a system into the system that they want/need it to be. They don't just say "well, looks like we have to throw the whole thing out the window and use this other new shiny/rebuild it from scratch". The desire to reinvent is important to keep throughout your years as long as it is rooted in reason and in the best intentions of the team and company.

Riffing on that, more senior engineers better know how to evolve those systems (whether that is working with larger systems or working on people problems or working to support large customers, etc)