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

Elitism as the mid-career growth engine

stkbailey.substack.com

Post reply on HN
Print view View original

71–80 of 115 posts

Re: Elitism as the mid-career growth engine

#71

Post by rcurry »

shubb wrote: post #6

Earlier in my career I felt a lot of disgust at bad code and bad solutions. Sometimes it tye badness was really effort due to unfamiliarity or not instantly understanding what I was looking at.my laziness. Sometimes it was because it disagreed with what ever framework or methodology I was using to give me confidence in the face of ignorance. I feel like an imposter but at least I know design patterns so this guy who…

This reminds me of my first experience with how executives think vs engineers. I was working for a day trading firm and was a hardcore C++ nerd at the time. We were having scalability issues and the CTO asked me if there was as anything I could do. So I tell him “Well, if you give us four or five weeks I think we can optimize the code and get about 30% better performance.” He just looks at me for a moment and then says “Or I could just buy another 25 servers, would that work? I can have them here in a few days.”

Re: Elitism as the mid-career growth engine

#72

Post by JohnFen »

hot_gril wrote: post #60
shubb wrote: post #6

Earlier in my career I felt a lot of disgust at bad code and bad solutions. Sometimes it tye badness was really effort due to unfamiliarity or not instantly understanding what I was looking at.my laziness. Sometimes it was because it disagreed with what ever framework or methodology I was using to give me confidence in the face of ignorance. I feel like an imposter but at least I know design patterns so this guy who…

I'm a young guy working with way more tenured and experienced programmers who didn't want management positions, preferring to code. Respectfully to them, I can't stand what they do. They obsess over details that do NOT matter to the business, and our whole department is paralyzed like this. Meanwhile big-picture things like internal APIs are either neglected or too big-brained for anyone to understand. I think they'r…

A good engineer creates solutions to the problem before them. That problem always includes constraints such as budget, deadlines, maintainability, etc.

Very often, the mathematically or logically "best" approach is not the correct engineering approach because it doesn't meet those practical requirements.

Engineers who insist on a sort of purity are, in my opinion, not the best engineers even if they are genius at writing code.

Re: Elitism as the mid-career growth engine

#73

Post by seymourhersh »

hot_gril wrote: post #62
seymourhersh wrote: post #61

Earlier quoted context omitted.

How do you know the details don’t matter? Often, not paying attention to the details leads to technical debt.

I know they don't matter when I end up being the guy to rewrite and own it, as has been my main job the past 4 (edit: 5 now) years.

That’s fair.

Re: Elitism as the mid-career growth engine

#74

Post by ChrisMarshallNY »

thefaux wrote: post #66
ChrisMarshallNY wrote: post #20

Earlier quoted context omitted.

Tell Linus his code sucks. That should end well.

Linus has a terrible attitude.

That may be so (I think so, myself), but there's no arguing with his prowess.

He was annoyed at his options for configuration management, so he took a couple of weeks off, and wrote Git[0].

Now, that kind of skill doesn't come in a Cracker Jack box...

[0] https://www.linuxfoundation.org/blog/blog/10-years-of-git-an...

Re: Elitism as the mid-career growth engine

#75

Post by feoren »

twobitshifter wrote: post #59

Maybe this helps in some places, but the negativity described here will not win you any friends when the subject is your coworker’s pull request and not a random journal article. I always try to see other perspectives and understand why a choice was made and get people to think instead of judging what’s been done. Working with “the smartest person in the room” who believes there’s only one right way to accomplish a g…

Sure, we should all make an effort to be diplomatic and not unnecessarily negative. But you're making a huge assumption: that the "smartest person in the room" is wrong. That's a nice, convenient, simple world where you can just ignore people that you disagree with by a-priori assuming they're wrong. Sorry to burst your bubble: sometimes (often?), these people are right.

People with decades of experience are often integrating thousands of lessons they've learned, in order to satisfy hundreds of individual constraints as best as they can. Consider the "Thinking Fast and Slow" anecdote about the fire chief who orders everyone out of the building, despite nothing obvious being wrong, because they have a gut feeling. If there's a culture of "Who made you the boss? Look at this guy, acting like he's the smartest guy in the room. If you're so smart, you should be able to explain to me why you believe we should all leave the building. All voices deserve to be heard. Sometimes the best ideas can come from ..." then everyone dies.

Look, I know we hate it when that arrogant sportsman is actually good at his sport. It's a bruising to our ego when the senior developer seemingly arrogantly insists on some standard or some change that isn't immediately obvious to you, and she doesn't immediately have the time to explain to you the 600 reasons why. She's probably a hell of a lot more critical of the idea than you are! She's already thought of, and worked through, every single objection you're raising, plus 100 more, and still decided this was the way to go. Yes, mentoring is important, and she probably does spend a lot of time doing that. (Maybe you're not willing to listen?) But not every moment has to be a healthy-debate all-ideas-welcome teaching moment. Sometimes you just fucking listen to the smartest guy in the room before the building collapses.

Re: Elitism as the mid-career growth engine

#76

Post by nerdponx »

idopmstuff wrote: post #39
ChrisMarshallNY wrote: post #23

Earlier quoted context omitted.

I worked the majority of my career at an "elite" Japanese corporation. It's one that has a brand pretty much synonymous with "Quality." Many of my peers were among the finest engineers and scientists in the world. I was often the dumbest guy in the room, and I'm smarter than the average bear. Dealing with these folks could be infuriating . Every time I would suggest orthogonal approaches (because, like, software is d…

I think the other thing that "over-engineered" can mean is code that's unnecessarily good for its purpose. If you're building a quick demo of a product to get user feedback, and you write perfect code that's highly maintainable, you've wasted time - better to throw together something as quick as you can and rebuild it if it's actually going to be used by/sold to customers. That's really overengineering in my mind - d…

I have come into serious conflict with one of my coworkers over this. He thinks everyone (except him) is either overengineering or underengineering everything all the time, but usually he just doesn't understand the problem context and is making assumptions that turn out to be incomplete or incorrect. It's a great lesson in humility to realize that no matter how smart or capable you are, you don't know what you don't know until you find out that you don't know it. I used to be a lot like him until I got slapped around pretty hard (metaphorically) as a result of my arrogance.

Re: Elitism as the mid-career growth engine

#77

Post by nerdponx »

vineyardmike wrote: post #65
idopmstuff wrote: post #39

Earlier quoted context omitted.

I think the other thing that "over-engineered" can mean is code that's unnecessarily good for its purpose. If you're building a quick demo of a product to get user feedback, and you write perfect code that's highly maintainable, you've wasted time - better to throw together something as quick as you can and rebuild it if it's actually going to be used by/sold to customers. That's really overengineering in my mind - d…

My advice to younger engineers is ALWAYS to remember demos don’t get rewritten. if a demo appears works, some one will want to ship it as is.

At the same time, not everything you ship needs to be a master work. "Working well enough to ship" is not the same as "flawlessly architected".

It also depends a lot on the business context, whether you can trust leadership to respect technical debt or not.

Re: Elitism as the mid-career growth engine

#78

Post by hot_gril »

feoren wrote: post #63
shubb wrote: post #6

Earlier in my career I felt a lot of disgust at bad code and bad solutions. Sometimes it tye badness was really effort due to unfamiliarity or not instantly understanding what I was looking at.my laziness. Sometimes it was because it disagreed with what ever framework or methodology I was using to give me confidence in the face of ignorance. I feel like an imposter but at least I know design patterns so this guy who…

> It's code. No one is going to read it. It will be replaced next year. Then it truly is awful. Deeply awful. It sounds like you've never progressed past dealing with terrible code, so you have my condolences. Good code is read. Good code is not replaced in a year. Even most bad code is not replaced in a year. Truly you live in a world of absolute shit code.

Business requirements or engineering dependencies can change quickly in some scenarios, meaning code gets replaced regardless of its quality. I've had to delete a lot of code the past few years, much of it 1 year old and very carefully written. Someone wasted his time.

Re: Elitism as the mid-career growth engine

#79

Post by nerdponx »

randomdata wrote: post #68
idopmstuff wrote: post #39

Earlier quoted context omitted.

I think the other thing that "over-engineered" can mean is code that's unnecessarily good for its purpose. If you're building a quick demo of a product to get user feedback, and you write perfect code that's highly maintainable, you've wasted time - better to throw together something as quick as you can and rebuild it if it's actually going to be used by/sold to customers. That's really overengineering in my mind - d…

> If you're building a quick demo of a product to get user feedback, and you write perfect code that's highly maintainable, you've wasted time Any time I thought I could shortcut my way to a demo by relaxing on perfect code/maintainable code it has always ended up taking just as much time and often longer.

Almost every time I've thought to myself "I will probably need to refactor this later", I did indeed need to refactor it later. But I think a lot of those cases I still made the right decision.

The initial version took M hours to develop, and the refactor took N hours. If I had done it right the first time, it would have taken L hours, where M < L < N + M. But it's not hard to construct legitimate business scenarios where the "N + M" solution is better than the "L" solution in terms of meeting the business goals.

Re: Elitism as the mid-career growth engine

#80

Post by nerdponx »

Tade0 wrote: post #16

I get where the author is coming from, but at the same time, having spent most of my career to date as a front-end developer, I can tell you many stories of how hilariously off the rails this approach can go. With a decade under my belt I'm feeling that I recently finally started learning and the conclusion so far is that half of the effectiveness of software engineering comes from obeying ultimately simple and commo…

> prefer pure functions and immutable data structures

This sounds like common sense until it becomes common nonsense, because you use Python or Javascript or Ruby or whatever language where you don't have an optimizing compiler and optimized immutable data structures, so what could have been be a single-pass low-memory scan over a big dataset in 10 minutes that could run on a toaster is implemented as an inefficient clusterfuck that takes 12 hours and 4 GB of memory.

It's absolutely important to treat mutability as either a side effect or a local optimization from a design perspective. But Python is not Clojure no matter how hard you try, and at some point you're going to want to mutate a dictionary.

Anyway, the point is that what might seem like "common sense" in some situations is not always obvious or unambiguous in general.

Post reply on HN