Live data from Hacker News

Drunk Post: Things I've Learned as a Sr Engineer

old.reddit.com

51–60 of 510 posts

Re: Drunk Post: Things I've Learned as a Sr Engineer

#51
post #18

>Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us. I thought they were going to go the direction of "he's an asshole" and was ready to accept that, but this particular criticism is actually disturbing. People with strong visions can often appear to be "making it up as they go along,…

A common meme I've seen recently is "no one knows what they're doing". I think people like to believe this because it helps them cope with impostor syndrome, or maybe they think it puts them on even ground with people who do in fact know what they're doing.

My model for people who "know what they're doing" is that they tend to have a well-organized hierarchy of rules. At the base are principles; at the top are opinions.

The foundation tends to be pretty simple, deeply held, and unchanging, while the higher levels are increasingly fluid and specialized. The higher you get on this stack, the more "making it up as you go along" it becomes, but every improvised part is perched on something more stable.

They key to "knowing what you're doing" is organizing this hierarchy well, having the right supports in place to successfully guide improvisation and course-correction while steadily fortifying the foundation.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#52
post #18

>Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us. I thought they were going to go the direction of "he's an asshole" and was ready to accept that, but this particular criticism is actually disturbing. People with strong visions can often appear to be "making it up as they go along,…

[deleted]

Re: Drunk Post: Things I've Learned as a Sr Engineer

#53

> When I first started, I was enamored with technology and programming and computer science. I'm over it. This is the saddest. One more soul taken by the shrinking of the hacker culture.

I don't know. Possibly it's simply because when you accept a career in the thing you're passionate about the thing you're passionate about becomes work. Another thought that has occurred to me of late: when I started in this field it was "Computers" (capital "C") — a thing really by nerds, for nerds. Increasingly it's the web, mobile. Our "customers" are increasingly not us and so the decisions that would have come s…

Yeah, I don't think there's anything special about working in tech. I've seen the same exact dynamic happen in lots of other fields. People who love cooking and become professional chefs only to leave after a few years is extremely common, for instance.

So much so that I would have said it is pretty common advice that if you try to turn a hobby you love into a job, there's a good chance you'll end up losing your passion for it.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#54
post #7
post #6

> I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so…

I think people in the industry are paid based on the potential value they can create (whether real or not), knowing many things or understanding fancy technologies matters little if one can't put them to use for the benefit of the company.

I've helped found multi-million dollar companies that I left before I could "cash out" because they were desktop based companies working with technology I considered growing stale and I wanted to switch to the web.

Now I'm doing the same thing with another company with the web, expect I'm handling everything as a sole-engineer, full stack.

Here I'm dealing with creating an Angular application to replace an aging ASP.Net MVC app, having to rewrite hundreds of SOAP services into a proper REST architecture, and dealing with an Oracle database who's schema we need to keep in place. With a C# .Net Core back-end.

This company needs me, badly, but I doubt this is going to be come a cash cow either (no equity, just a paycheck, and their budget is tight).

Just doing my job as usual.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#55
post #18

>Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us. I thought they were going to go the direction of "he's an asshole" and was ready to accept that, but this particular criticism is actually disturbing. People with strong visions can often appear to be "making it up as they go along,…

The criticism may depend on different values of "making it up as you go along", i.e., it may not mean so much "just wing it in ignorance" vs something like "even if you have many answers you don't yet have all of them, and new answers generate new questions exponentially...". So, perhaps less "everyone's ignorant" vs "we're all living in a land of many unknowns". But, yeah, he did find it disillusioning, and maybe is over-generalizing from a one-off experience (in contrast, I've done similar and was nothing but impressed, finding it is extremely valuable to learn from the best in a field).

How do you distinguish between what you do and "making it up as you go along"?

Re: Drunk Post: Things I've Learned as a Sr Engineer

#56
post #5

> Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all. This a thousand times. Having empathy for future devs, maintenance, and bug fixes is so important.

This sentiment is exactly why programming in an org-chart is so much different than programming as an individual. Don't apply corporate best practice designed to withstand turnover to personal programming - you're leaving abstraction and efficiency on the table. The better code for your own projects is almost definitely inscrutable to a newcomer a lot of the time. It's okay for there to be prerequisites to understand…

I agree with this in principle but in practice code I write that’s quick & easy and not very readable is usually not understandable by me in a few months either. So if it’s a personal project I hope to last I still want to keep it simple with my code.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#57
post #44

Earlier quoted context omitted.

i was debugging some very terse, elegant, and dense code. i added a bunch of logging throughout to understand what was going wrong. someone then removed all of my logging because it was ugly. and then had to put it all back in when another bug was coming from the same terse beautiful code.

That hurt me to read! Have you communicated this to your manager? Might be worthwhile to have a decision "from the top" that is essentially: all logging is good, so long as it doesn't hurt performance or contain PII/PHI.

Logging is like a lamp in the dark, you need it.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#58
post #22

Earlier quoted context omitted.

Amen. Something bizarre I have noticed though in junior-almost-senior engineers is that they pride themselves in obfuscating and writing "highly complex" logic, with no documentation. It's almost like they are demonstrating their new abilities in the worst way possible. I have been dealing with one of these engineers recently, and they have expressed to me that they love writing because it's so terse. It's been a poi…

I wish more managers and business stakeholders investigated this more carefully. Team members of this type add a shadow overhead that impacts velocity dramatically. It’s always visible to average competent devs on the team, but can be invisible to managers who don’t investigate as to why only one person is particularly productive on the team. Most people won’t go to their bosses and say ‘so and so writes overly compl…

I would do this auditing job, no joke. A kind of "code-smell" service, that can yield problematic areas, along with a report of engineers that could use additional guidance/training/reigning-in would be super valuable from a manager's perspective. And because it's a neutral party, they can feel good that there's no politics.

One challenging bit about this service would definitely be quantifying improvements. Since the problem is somewhat hidden by nature, you would almost need testimonials from other engineers on the team.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#59

Earlier quoted context omitted.

This sentiment is exactly why programming in an org-chart is so much different than programming as an individual. Don't apply corporate best practice designed to withstand turnover to personal programming - you're leaving abstraction and efficiency on the table. The better code for your own projects is almost definitely inscrutable to a newcomer a lot of the time. It's okay for there to be prerequisites to understand…

I agree with this in principle but in practice code I write that’s quick & easy and not very readable is usually not understandable by me in a few months either. So if it’s a personal project I hope to last I still want to keep it simple with my code.

I'm not saying to hack away and make a mess necessarily.

Sometimes the simplest solution also requires learning and building upon other concepts. Or sometimes, a simple interface is written around a complicated core.

For example: The OP's quote is used time and time again to argue against FP concepts in industry - a newcomer doesn't know the first principles, so by the OP's folksy razor[1], that code isn't as good as less abstract code that doesn't require learning a new concept or two once and for all.

[1] Folksy razors are the essence of every principle-ish-level engineer's methodology I've run into. Corporations value the ability to remove all human agency & decision-making from software development where possible.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#60
post #18

>Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us. I thought they were going to go the direction of "he's an asshole" and was ready to accept that, but this particular criticism is actually disturbing. People with strong visions can often appear to be "making it up as they go along,…

> built a framework for spinning up new fully-deployable services from scratch that gets engineers 90% of the way there (minus the business logic)

I'm guessing that this was based on first-hand experience building such services and witnessing engineers struggle getting new services up. And not so much that you've had specific training or past experience in developing bootstrapping frameworks. This would be my definition of making it up as you go and is great way to do it. Another way is learning how to make bootstrapping frameworks and applying it wherever you can which doesn't go as well.

Post reply on HN