Hacker News new | ask | show | jobs
by taylodl 3072 days ago
"Senior engineers sometimes need to be reminded that highly performant, abstract, or clever code is often difficult to read and understand later, which usually means asking them for more inline comments and documentation."

Ha! That's not a senior engineer. Senior engineers write the most simple-looking code that just works. In every rainy day scenario imaginable. The clever code writers aren't there yet.

6 comments

Reminds me of the "Evolution of a Haskell programmer":

https://www.willamette.edu/~fruehr/haskell/evolution.html

Make sure you don't miss the punchline, "Tenured professor".

It's the same with the progression of engineering seniority: increasing levels of cleverness and unnecessary sophistication, until you reach a point where you don't have anything to prove anymore, and you can feel comfortable writing the simplest and most elegant solution.

That was great— though not being versed in Haskell, I tried to follow their link to the original version, but it had died.

Here's the original:

http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer....

The punchline got me pretty good.

It's kind of amusing to me that a lot of engineering interviews also seem to be focused on doing things that you generally won't and shouldn't be doing for the position. What's the point of seeing if someone knows data structures and algorithms they won't be using if they can't write a web application that interfaces with a SQL database without doing queries in a for loop?
> What's the point of seeing if someone knows data structures and algorithms they won't be using if they can't write a web application that interfaces with a SQL database without doing queries in a for loop?

Isn't this the basic architecture of a node js "event loop" Cms that gets content from a rdbms? ;-)

  # pseudo code
  While new_user_request
    query_db with request parameters
I know it's not what you meant, you meant do the above, rather than:

    # pseudo code
  While new_user_request
    query_db for user data
    query_db for session data

    For parameter,
        user_data,
        session_data
        query_db with each item
I've been doing a lot of Haskell on Codewars.com recently. This is exactly what I see. I write up a long solution, that uses the basics like pattern matching, heads of lists and such. The solution that has the most "Best practise" up-votes are usually something involving importing control.monad and other similar stuff.
If you write code that other people have to ask you about, you will reach a point where you don’t have time to write code anymore because you’re too busy answering for your own code. You may interpret this as “helping your less fortunate teammates” but the wise know they can reduce your influence on the team by sending more people to ask you questions.

Giving them more time to clean up your mess and you none to make it worse.

Sites like Codewars seem to me like good ideas starting out, but it doesn't take that long to turn into an arms race of complex one liners that people vote up as the coolest solution, not the best in terms of productivity for a company.
Ha it does make me think of this tweet https://twitter.com/KevlinHenney/status/381021802941906944

You nailed it really, senior engineers code is the most simple looking as generally they've picked the right abstraction for the problem.

Is this a senior engineers are literally superheroes meme I've missed?

Everyone is capable of making poor decisions and straight up logic errors. Senior devs sometimes more-so because we tend to get entrenched in a particular issue solo for longer periods.

Not at all and it's now how I view senior engineers. True senior engineers though do tend to find the right abstractions more often than other engineers but it doesn't mean they can't make huge mistakes with bigger implications.

My thoughts are also on actual senior engineers, not 2 years of experience etc.

I think of it more as a 'no true senior engineer' argument.
Text of the tweet so people don't have to click:

A common fallacy is to assume authors of incomprehensible code will somehow be able to express themselves lucidly and clearly in comments.

Senior Engineers are probably in meetings, not writing code..
ding ding ding
There is a conundrum here: architectural mismatch.

Often, the "right abstraction" for a problem is not call/return based. So you get to choose between having the right abstraction, and code that is simple when viewed with that abstraction in mind, but "weird". Or alternatively choose the wrong but better-supported abstraction and have code that is needlessly complex but "straightforward".

> they've picked the right abstraction for the problem

I hate to agree with you, but "picking the right abstraction for the problem" elegantly expresses what I've been trying to tell people for the last few years now, but far less succinctly (I usually ramble on about "underlying data models" and "what this actually is in the real world, not just how we view it in our application")

The reason I hate to agree with you is that I just became very disappointed that this is a difficult skill to master. "Just use the right model and the code is easy, duh. Why aren't you doing this?" Well. Now I just feel like a jerk. I thought they just gave me the "senior" title because I was old.

It's unfortunate that one of the most important skills in the industry is so intangible and difficult to quantify. Even more difficult to teach.

Ha! That's good engineers. Senior engineers write an ambitious unusable framework, get promoted and move on to the next project. So the article's advice is ironically spot on.
Tell me more about getting them to move on. I’m asking for a friend.
We call people senior after five years. Mastery can take a lot longer than that (and mastery doesn’t mean the end of learning).

Sooner or later someone will have to debug this code late at night. Don’t make it require brain cells.

is this a no true scottsman?
That might be true in theory, but in practice most people I know with that title (& most with titles above it) do this sort of thing more often than junior developers.