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

81–90 of 510 posts

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

#81

Post by m45t3r »

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…

I think there is Clojure and cloJure. The language is very different if you can mostly get by writing pure Clojure code, and another language altogether if you need to interop with Java constantly.

If you can get by mostly writing Clojure code (either by wrapping the Java libraries that you will use on helpers, or by using third-party libraries), it is a great language, even if in the end it is a very different from any other Lisp (but I'd argue that the changes are for the better, for example first instead of car, thread macros, protocols, immutable data structures). But yeah, for sure Clojure is much more optionated than any other Lisp.

Now, if you need to interop with Java code constantly, yeah, Clojure can be a pain. A good chunk of the code you will write goes to appease the alien structure that is the concept of Class on a FP language.

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

#82

Post by swader999 »

josephorjoe wrote: post #68
sharken wrote: post #57

Earlier quoted context omitted.

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

three things i find to be true of every web app i work on: 1. good logging is the most important part of the app. whatever the app is meant to do is secondary. the app should be a logging app first, and then a backend service to sell widgets second. 2. assume performance requirements for request latency and transactions per second will be at least 3x whatever the product owner tells you at the start of the project an…

Logging at the boundaries or seems is especially helpful.

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

#83

Post by mplanchard »

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…

IME good commenting alleviates a lot of the “problems” with using complex language features. I’m thinking redis style comments (see here[0] for antirez’s philosophy on the issue). If you’re doing something that’s not immediately obvious, explain what you’re doing! That way others can verify it during review, and when someone is reading the code later they can read the comment to understand what’s happening rather than having to parse the code. IMO this applies just as much to simple constructs as to complex ones. Big for loop? Throw a comment at the top telling me what it does so I don’t have to read it when I’m skimming later. Better yet use `map` with a well-named function. Either way, provide a semantically meaningful summary of what’s happening.

[0]: http://antirez.com/news/124

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

#84

Post by whateveracct »

pbourke wrote: post #71
whateveracct wrote: post #59

Earlier quoted context omitted.

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…

> Corporations value the ability to remove all human agency & decision-making from software development where possible. Corporations value the ability to continue as an operating entity and make changes to the code after the proponent of Kleisli arrows and lenses has departed for greener pastures.

Doesn't mean I have to respect for be sympathetic to it. It is just organized stupidity at scale.

That said, it's hard not to play the game and buy in. I just write my vanilla Java, say right-sounding things in meetings, and somehow get Paid despite barely doing a thing.

Corporate software development is a great career tbh - instead of paying me to use Kleisli arrows for the company's gain, the company effectively pays me to use Kleisli arrows on my own IP lmao. Gotta love all that frothy waste that's produced by Worse is Better. Waste that the average dev can now reap thanks to the boom in remote work!

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

#85

Post by sharken »

> If I'm awaken at 2am from being on-call for more than once per quarter, then something is seriously wrong and I will either fix it or quit.

Sometimes fixing the problem will require special access to Production which you don't have, or even a specific role with that extra bit of initiative.

Otherwise i agree 100%.

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

#86

Post by actinium226 »

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 agree with having empathy for future devs, but I think it only goes so far. I've often seen junior engineers unable to differentiate between code they don't understand and bad code.

Usually they end up thinking they can do a better job, decide to rewrite the thing from scratch, and take 10x longer to rewrite it than they thought it would take. And accomplish nothing in the end, because the thing they rewrote worked in the first place.

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

#87

Post by dataflow »

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) accessible to an entry level engineer. Some technologies just take a long time to master, and doing that can also require higher-level abstractions.

So I would say great code is code that:

1. Does its job well (robustly, performantly, etc. in whatever proportion is applicable)

2. Is maintainable by engineers with reasonable expertise in the tooling

in that order. If you can manage all that and make it accessible to your junior devs, that will of course make your code greater. But don't lose sight of what your customers care about. Your business isn't there to make you feel good about maintaining code, it's to provide customers with value.

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

#88

Post by whateveracct »

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…

Exactly.

How many entry level engineers come onto a project per year? 5? Is onboarding them onto the project is a deliberate and streamlined way such an undue burden that you must change your programming style to avoid it?

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

#89

Post by tgv »

JKCalhoun wrote: post #42
ilrwbwrkhv wrote: post #13

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

There are quite a few topics in CS I like, from compiler construction to robotics. That was the "hacker tech" for me. For a long time, I managed to have work with an interesting angle, but slowly it got to the point where I'm solving a fucking npm caching problem that caused a junior headaches, moving a server with an EOL OS with minimal service interruption, looking for another 2FA mechanism, and getting older tools to play well with mobile. None of it is interesting, and it takes a lot of time.

Not that it used to be better: many of my fellow students ended up in business administration. Some might even be architecturing COBOL systems on an IBM mainframe.

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

#90

Post by MaxBarraclough »

mplanchard wrote: post #83
MaxBarraclough wrote: post #63

Earlier quoted context omitted.

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…

IME good commenting alleviates a lot of the “problems” with using complex language features. I’m thinking redis style comments (see here[0] for antirez’s philosophy on the issue). If you’re doing something that’s not immediately obvious, explain what you’re doing! That way others can verify it during review, and when someone is reading the code later they can read the comment to understand what’s happening rather tha…

> If you’re doing something that’s not immediately obvious, explain what you’re doing!

Agreed. Comments have their place, and some code is unavoidably involved, just by the nature of unavoidable complexity. The solution isn't always to write simple code. If it were, we wouldn't bother studying clever and efficient algorithms.

Also, it's important to ensure comments are updated when code is changed. I don't know who originally said it: Stale and inaccurate comments are no longer comments, they're lies.

That blog post looks worth reading properly, I admit so far I've only skimmed it.

Post reply on HN