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.
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.
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.
Here's the original:
http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer....
The punchline got me pretty good.
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 itemGiving them more time to clean up your mess and you none to make it worse.
You nailed it really, senior engineers code is the most simple looking as generally they've picked the right abstraction for the problem.
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.
My thoughts are also on actual senior engineers, not 2 years of experience etc.
A common fallacy is to assume authors of incomprehensible code will somehow be able to express themselves lucidly and clearly in comments.
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".
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.
Sooner or later someone will have to debug this code late at night. Don’t make it require brain cells.