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

Show HN: A Senior Engineer's CheckList

news.ycombinator.com

Post reply on HN
Print view View original

101–110 of 155 posts

Re: Show HN: A Senior Engineer's CheckList

#101

Post by jayrwren »

galaktor wrote: post #60
rekabis wrote: post #28

Earlier quoted context omitted.

Second bullet point: recommend using “strong opinions weakly held” ( https://medium.com/@ameet/strong-opinions-weakly-held-a-fram... ). Always be ready to review any opinion you have in the face of new evidence. In fact, seek out information that will challenge your opinions. But until the burden of evidence favours another opinion over yours, be prepared to hold and defend your opinions stridently.

> until the burden of evidence favours another opinion over yours, be prepared to hold and defend your opinions stridently It might seem obvious, but this part is extremely important and can be very difficult to live by because it encourages (healthy) disagreement and conflict. "Strong opinions, weakly held" is explicitly _not_ about giving in to a majority opinion or because the opinion is coming from a position of…

> It's essentially the scientific method.

I had never considered this before and it is right and true.

Thank you for enlightening me.

Re: Show HN: A Senior Engineer's CheckList

#102

Post by mgkimsal »

DarkWiiPlayer wrote: post #100
mgkimsal wrote: post #96

Earlier quoted context omitted.

The opposite can happen. Took over a system in Aug '18 with someone else. Previous 'senior engineer' had left after a year to go be a CTO someplace else. Everything seemed wrong - bad smells everywhere, spidey-sense a-tinging every day. In October, we found that code put in place had been losing data since April - we had 6 months of pure data loss. Data that people assumed was 'working' because ... they hit a button…

That's why I think code that seems "weird" should always be accompanied by a comment explaining why it is the way it is and why a seemingly more obvious approach wasn't taken.

At the very least.

Better might be a comment linking to a ticket or wiki page or internal README with far more explanation. What's the technical reasoning, and what was the business impetus for requiring this done this way at this time?

Again, I've been on both sides of this fence, but the "never rebuild" mantra has a lot of assumptions built in, chief being that things are actually working correctly. If they are, and there's no tests around it, memorialize the existing state with your own tests at the very start. It's what we did on the August project referenced above, and it took weeks (months, really) to have a modicum of basic tests ensuring some base level of understanding for our team (just 2 of us).

Re: Show HN: A Senior Engineer's CheckList

#103

Post by jacekm »

mgkimsal wrote: post #96
dbmikus wrote: post #53

About this one: > Respect code and systems that came before you. There are reasons for every code and every guard that exists in production Sometimes there's bad code in prod, or code that doesn't need to exist anymore. You should try to understand when something is there for a good reason versus a bad reason. Cut out the bad code, keep the good code. I've seen a lot of cases where people assume that current code is…

The opposite can happen. Took over a system in Aug '18 with someone else. Previous 'senior engineer' had left after a year to go be a CTO someplace else. Everything seemed wrong - bad smells everywhere, spidey-sense a-tinging every day. In October, we found that code put in place had been losing data since April - we had 6 months of pure data loss. Data that people assumed was 'working' because ... they hit a button…

I think respect does not imply assumption of correctness. It's more like: there's a reason why the code looks like it does. The reason could be time pressure, some crucial information missing at the time when it was being implemented, etc. By all means try to improve it but don't look down on a person who created it. It's easy to judge from perspective of 6 or more months.

Re: Show HN: A Senior Engineer's CheckList

#104

Post by msluyter »

dbmikus wrote: post #53

About this one: > Respect code and systems that came before you. There are reasons for every code and every guard that exists in production Sometimes there's bad code in prod, or code that doesn't need to exist anymore. You should try to understand when something is there for a good reason versus a bad reason. Cut out the bad code, keep the good code. I've seen a lot of cases where people assume that current code is…

AKA, Chesterson's Fence:

https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

Re: Show HN: A Senior Engineer's CheckList

#105

Post by mgkimsal »

jacekm wrote: post #103
mgkimsal wrote: post #96

Earlier quoted context omitted.

The opposite can happen. Took over a system in Aug '18 with someone else. Previous 'senior engineer' had left after a year to go be a CTO someplace else. Everything seemed wrong - bad smells everywhere, spidey-sense a-tinging every day. In October, we found that code put in place had been losing data since April - we had 6 months of pure data loss. Data that people assumed was 'working' because ... they hit a button…

I think respect does not imply assumption of correctness. It's more like: there's a reason why the code looks like it does. The reason could be time pressure, some crucial information missing at the time when it was being implemented, etc. By all means try to improve it but don't look down on a person who created it. It's easy to judge from perspective of 6 or more months.

"The reason" can also be lack of basic competence in previous workers. That can be extended to the rest of the team or management around the worker(s) for not providing a guidance/help.

"reason" can be "cause/effect" reason, but also "justifiable rationale". The files look like they do because someone typed keys and hit 'save' - cause/effect. But there's often no justification for how some code exists in its state that has to do with issues related to the business/logic itself. External factors - time (as you mentioned) or missing info (as you mentioned) - that missing info should have been documented somewhere.

I put out a lot of bad code in my early days. Seniors who came in afterwards ... yeah, the only or primary reason they could get from my code was "he wasn't very good at this". And they were correct. I got better, but primarily through trial and error (lots of them).

In thinking of some specific projects from 98/99 - I was demonstrably not good. I got stuff done, but it was generally very inefficient. But... it worked (to the level of understanding of everyone on the project). Even then, people weren't coming in after me to make basic stuff work, but they did help make it better.

If you're coming in to a project and there's no unit tests, no sample data, no repeatable build process, no documentation, no testing or verification process, and no previous team members to actually talk to to get questions answered, there's little reason to have any assumption of correctness. There may very well be 'reasons' for the lack of all of those factors above, but nothing makes me assume the code is correct. And... if I'm brought in to a project like that, "respecting" the code or the people before adds no benefit to the project, and may detract from getting stuff done.

Re: Show HN: A Senior Engineer's CheckList

#106

Post by hutzlibu »

LandR wrote: post #73
notTyler wrote: post #41

'Get involved with hiring for your team and company, and maintain a high bar for hiring quality candidates.' Posts derailing this 'high bar' are posted semi-daily to Hacker News, no? It's a really big dilemma (extensive hiring process that weeds out good candidates due to time and frustration or take risks) and it makes it sound like it's just something, you can, you know, do on a Tuesday in your spare time, and then…

Especially nowadays when Developers don't seem to have to be required to actually be able to code. I'm not part of the hiring process at our place but from what I've tried to contribute as a potential technical test, I get told it's too hard... It's really really not hard at all. But from what I can tell if you ask them to code, even in their own time or in the interview, that's unfair and stressful and you aren't se…

So you want to implement an age measure of qualification, since you cannot get hiring to implement a good technical interview process? Do you also write code the same way?

Re: Show HN: A Senior Engineer's CheckList

#107

Post by grumpy8 »

>> extreme ownership

This is my biggest pet peeve with junior developers. I find there's a total lack of ownership about making sure the feature is completely wrapped-up (not just the code, but the tests, the metrics, that it's shipped, that it's correctly marked as done and communicated, etc.)

I find they /expect/ that someone else at the company will review and make sure everything is done and safe, rather than be proactive about it.

Re: Show HN: A Senior Engineer's CheckList

#108

Post by crispyambulance »

grumpy8 wrote: post #107

>> extreme ownership This is my biggest pet peeve with junior developers. I find there's a total lack of ownership about making sure the feature is completely wrapped-up (not just the code, but the tests, the metrics, that it's shipped, that it's correctly marked as done and communicated, etc.) I find they /expect/ that someone else at the company will review and make sure everything is done and safe, rather than be…

"Extreme ownership" is something that takes time to develop.

It's why chefs-in-training at elite restaurants chop vegetables, mop floors and perform other menial task for an uncanny amount of time before proceeding to other things.

It's OK for junior folks to not see the big picture. I'd be FAR more concerned about heavily silo'd senior engineers only focusing on one thing.

Re: Show HN: A Senior Engineer's CheckList

#109

Post by DePro »

I was recently trying to make something like this checklist, but categorized a little differently, with multiple levels of detail, and... extensive.

As above, visit [1] for the end-user version and [2] for the repository.

1. http://htmlpreview.github.io/?https://github.com/dpmm99/deve...

2. https://github.com/dpmm99/developer-knowledge/

Re: Show HN: A Senior Engineer's CheckList

#110

Post by vorpalhex »

mgkimsal wrote: post #105
jacekm wrote: post #103

Earlier quoted context omitted.

I think respect does not imply assumption of correctness. It's more like: there's a reason why the code looks like it does. The reason could be time pressure, some crucial information missing at the time when it was being implemented, etc. By all means try to improve it but don't look down on a person who created it. It's easy to judge from perspective of 6 or more months.

"The reason" can also be lack of basic competence in previous workers. That can be extended to the rest of the team or management around the worker(s) for not providing a guidance/help. "reason" can be "cause/effect" reason, but also "justifiable rationale". The files look like they do because someone typed keys and hit 'save' - cause/effect. But there's often no justification for how some code exists in its state th…

It's not an assumption of correctness. It's an assumption of purpose. Chesterton's fence[1].

Let's say you inherit a large codebase, and it in fact does not have any tests, and is relatively complex and convoluted. Obviously that's not going to be very maintainable without testing, and it may make sense to do a rewrite...

But first, write tests. Test your assumptions. Read the commit history and see how the code base evolved over time. Maybe the reasons it was built the way it was are dumb ("I like naming my variables after my favorite flavors of pie!") or maybe it was done for really good reasons ("The database library breaks with odd numbers of connections, so the pool always has to be an even number."). The issue is that you simply don't know and risk repeating your ancestors mistakes unless you do some investigation.

[1] - https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

Post reply on HN