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

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

old.reddit.com

Post reply on HN
Print view View original

91–100 of 510 posts

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

#91

Post by AlexCoventry »

creamytaco wrote: post #62
sundvor wrote: post #33

Earlier quoted context omitted.

Do it, if only to find Clojure.

Clojure goes against so many of lisp's timeless philosophies and principles that it can hardly be described as a lisp. When someone says "lisp is the greatest programming language" it's these principles that they refer to, most of which Clojure discards so it can play nice with Java and promote very specialized ways of solving problems in order to best fit a particular niche. The best way to discover the essence of l…

Which of Lisp's philosophies and principles does Clojure violate?

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

#92

Post by derangedHorse »

daenz wrote: post #58
runawaybottle wrote: post #37

Earlier quoted context omitted.

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 th…

Testimonials aren't a bad thing though. I think every dev should have their code read and evaluated by at least one other person, although getting as many people as possible to read it would be best. If code legibility to help team members understand, debug, and improve upon the code is essential, the best metric to use for code quality would be their collective feedback on said code.

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

#93

Post by andy_ppp »

dataflow wrote: post #87
eqmvii wrote: 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.

I disagree strongly with it on multiple fronts. That concern should be secondary to your program actually doing its job well. Your customer will literally not care how elegant or ugly your code is; they just see the end result. And when the program fails them, it really doesn't matter to them whether your juniors understand the code or the error. Moreover, not every abstraction is (or can be expected to be) accessibl…

This assumes you are absolutely certain you know what the code should do. And that it does what you think it does. Hence while you might think “performs its task” is an easily defined I’d disagree. I’d take clear code that wasn’t working over code that was hard to reason about and somehow worked every day.

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

#94

Post by joncp »

the_arun wrote: post #8

Probably people are honest when they are drunk. There is nothing to argue with any of those comments. But this one stood out for me! > Titles mostly don't matter. Principal Distinguished Staff Lead Engineer from Whatever Company, whatever. What did you do and what did you accomplish. That's all people care about.

That's true unless you get acquired. At that point, your title is what your new overlords will use to determine your role, salary, and even whether to lay you off.

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

#95

Post by mgfist »

andy_ppp wrote: post #93
dataflow wrote: post #87

Earlier quoted context omitted.

I disagree strongly with it on multiple fronts. That concern should be secondary to your program actually doing its job well. Your customer will literally not care how elegant or ugly your code is; they just see the end result. And when the program fails them, it really doesn't matter to them whether your juniors understand the code or the error. Moreover, not every abstraction is (or can be expected to be) accessibl…

This assumes you are absolutely certain you know what the code should do. And that it does what you think it does. Hence while you might think “performs its task” is an easily defined I’d disagree. I’d take clear code that wasn’t working over code that was hard to reason about and somehow worked every day.

> I’d take clear code that wasn’t working over code that was hard to reason about and somehow worked every day.

Then you'd be out of business.

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

#96

Post by gravypod »

dataflow wrote: post #87
eqmvii wrote: 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.

I disagree strongly with it on multiple fronts. That concern should be secondary to your program actually doing its job well. Your customer will literally not care how elegant or ugly your code is; they just see the end result. And when the program fails them, it really doesn't matter to them whether your juniors understand the code or the error. Moreover, not every abstraction is (or can be expected to be) accessibl…

It depends on what you're optimizing for. I like to think of it this way. A good "programmer" can take ideas and turn them into working software that is performant enough, meets all of the requirements, etc. This is a mostly static operation. A good "engineer" can take ideas and turn them into working software that can be changed, updated, and maintained for years to decades by multiple programmers.

There are code bases at my current employer that are entirely "ok" and still being worked on from before I was able to spell my name. Projects that have had continued development for >20 years by armies of engineers and the code is still readable and simple to understand.

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

#97

Post by BobbyJo »

dataflow wrote: post #87
eqmvii wrote: 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.

I disagree strongly with it on multiple fronts. That concern should be secondary to your program actually doing its job well. Your customer will literally not care how elegant or ugly your code is; they just see the end result. And when the program fails them, it really doesn't matter to them whether your juniors understand the code or the error. Moreover, not every abstraction is (or can be expected to be) accessibl…

I strongly disagree. You're packing a bunch of different metrics of quality into a single bullet and somehow suggesting those are separate than the second bullet point. Readability is just as dependent a metric as the others. If you make things that are hard to read, I can guarantee they are not going to be robust, as well as likely not performant.

In my experience, the easiest to maintain code is very often the most efficient and robust as well, because people haven't felt the need to hack around it at every corner.

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

#98

Post by manigandham »

EMM_386 wrote: 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…

The issue is in actually using all that knowledge in a single position and creating enough value. Larger organizations have specialized teams that move faster at their function rather than generalized devs.

The way for full-stack devs to profit most is to work at smaller companies and trade that for equity and seniority.

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

#99

Post by 29athrowaway »

> Work from home is the tits. But lack of whiteboarding sucks.

Just get yourself a drawing tablet and some whiteboard software like Openboard (http://openboard.ch/index.en.html).

> Good people write shitty code. Smart people write shitty code. Good coders and good engineers write shitty code. Don't let code quality be a dependent variable on your self worth.

That's like saying that eminent book authors write shitty books. Sounds like an excuse.

> I've become what I've always hated: someone who works in tech in a career but avoid tech in real life. Maybe that comes with being old.

It's all about finding the right project. REST + CRUD shit gets exhausting after 5 years. There's an entire world of excitement outside of REST + CRUD.

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

#100

Post by sweeneyrod »

MaxBarraclough wrote: post #63
eqmvii wrote: 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.

It goes too far though. The virtue of simplicity needs to be balanced against the virtue of making proper use of advanced language features. A first-year student is unlikely to understand C++ template metaprogramming, or just about any Haskell code, but that's not to say they should always be avoided in production code. > The best code is no code at all This can be interpreted as advice to avoid the 'inner-platform e…

There are various universities that teach Haskell or similar languages in first year.
Post reply on HN