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

51–60 of 155 posts

Re: Show HN: A Senior Engineer's CheckList

#51

Post by dancek »

wyldfire wrote: post #18

Thanks for sharing. I would instead describe this list as "principles" instead of a checklist. A checklist is often used for a much more specific scope with very specific items. These are not applicable to any specific time or scenario and have activities that are not very specific. Here's my thoughts on a few of the items themselves: "Follow the principles of extreme ownership." -- Unless the term "extreme ownership…

Extreme ownership probably refers to the book Extreme Ownership: How U.S. Navy SEALs Lead and Win.

Re: Show HN: A Senior Engineer's CheckList

#53

Post by dbmikus »

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 untouchable or designed very intentionally, so they wrap it and then you end up with a tower of abstractions built on a poor base.

So, I think as a senior engineer you should try to understand the difference between code that should stay and code that should go.

Re: Show HN: A Senior Engineer's CheckList

#54

Post by 29athrowaway »

LaGrange wrote: post #20
29athrowaway wrote: post #14

> "Understand the business aspect of your work, and what makes money. Eventually, only that matters." How about ethics? company reputation? legal compliance? corporate responsibility?

Caring about ethics is too old fashioned for software "engineering," reputation is maintained by someone else, software developers tend to think the law happens to other people and HAHAHAHAHA. ...that's about it.

Engineers at a known european auto maker created a solution to defeat car emissions tests. As a result, there were cars on the streets that polluted hundreds of times more than a regular car.

Delivery and ridesharing apps have algorithms that are almost indifferent from tip skimming. Many people working on those platforms live in financial hardship.

In an east asian country, people live under constant surveillance: physical (cameras, face detection), financial, and online activity. If you criticize the government you lose access to everything: payments, transport, credit, job, etc.

If you were paid a lot of money, would you implement those "solutions"?

That is the importance of ethics.

Re: Show HN: A Senior Engineer's CheckList

#55

Post by 29athrowaway »

tracer4201 wrote: post #22
29athrowaway wrote: post #14

> "Understand the business aspect of your work, and what makes money. Eventually, only that matters." How about ethics? company reputation? legal compliance? corporate responsibility?

Your post comes off as if the author is purposely avoiding these topics. No doubt they’re important, but while many software people will look at a company’s reputation or take ethics for granted (in the sense that of course it’s important), many software people, especially juniors, don’t stop to think about the business value of spending X on Y. Everything has a cost - for example, spending the extra time optimizing…

You are conflating software engineering good practices with ethics. They slightly overlap but are not the same.

Balancing strategy and tactics is something you do as you become senior. Pumping tech debt is a tactic, good practices are a strategy.

Re: Show HN: A Senior Engineer's CheckList

#56

Post by cb504 »

29athrowaway wrote: post #14

> "Understand the business aspect of your work, and what makes money. Eventually, only that matters." How about ethics? company reputation? legal compliance? corporate responsibility?

In addition to the ethical aspects of the product, I would add, that I always ask myself, "if I was laid off today, can I use my current job to get another job."

I worked at a company where the the work I was assigned was undermining my career to the point that if I didn't do something on the side, I wouldn't be able to pass an interview.

So while the business aspect is important, it is not the only thing that matters; it never is.

Re: Show HN: A Senior Engineer's CheckList

#57

Post by imafish »

ben_jones wrote: post #9
j05huaNathaniel wrote: post #5

Earlier quoted context omitted.

Your comment seems pretty elitist. It's clearly implying that Software Engineers aren't real engineers. I'll admit, not every software developer designs and builds engines (see definition of engine) but many Software Engineers, in fact, do. The principles of engineering are simply applied sciences. Many software engineers have degrees in Computer Science and they are applying the science. I also know plenty of Softwa…

But you can't deny there is a pervasive overuse of the label 'engineer' to cover everything from junior web developers with < 1 year experience all the way to senior roles at major companies. The label has an important meaning to non-technical readers and should be used more sparingly.

So a mechanical engineer with < 1 year experience should also be called a junior mechanical developer.. or am I missing the point here?

Re: Show HN: A Senior Engineer's CheckList

#58

Post by imafish »

j05huaNathaniel wrote: post #5
visviva wrote: post #3

Normally, this is where I'd chide the OP for using "Engineer" in the title when they really mean "Software Engineer", but (refreshingly) most of the items on this list seem broadly applicable to different types of engineers, so it's not really warranted.

Your comment seems pretty elitist. It's clearly implying that Software Engineers aren't real engineers. I'll admit, not every software developer designs and builds engines (see definition of engine) but many Software Engineers, in fact, do. The principles of engineering are simply applied sciences. Many software engineers have degrees in Computer Science and they are applying the science. I also know plenty of Softwa…

I think you misunderstood him, as others have noted, however I do agree that Software Engineers tend to diminish their own skillset as not "engineery" enough. And I have a very hard time understanding why.

I work with many kinds of engineers, every day, from electrical to mechanical, and I do not find their way of working any more advanced than what I have become used to from disciplines of Software Engineering.

I look at some of their math and think magic. They look at my code and think magic. However, anything else seems pretty much the same. We do iterative development, they do iterative development, although less sophisticated and with much longer feedback loops, so they have higher incentives to get designs right the first time - but that does not mean that they always do!

Re: Show HN: A Senior Engineer's CheckList

#59

Post by manojlds »

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…

I think the main thrust is respect the code and understand why it was there. Don't start with the possible initial feeling that a particular piece of code or guard is not needed. If you do find that it's not needed, remove it or fix it.

Re: Show HN: A Senior Engineer's CheckList

#60

Post by galaktor »

rekabis wrote: post #28
tmh88j wrote: post #4

Thanks for the list. There are a lot of great suggestions here, but I think the scope is much wider than just senior engineers for a majority of the items. Here are a few that I think are especially important for junior level engineers. • Question everything and ask “why” repetitively until you get to the root of problems and situations. • Do not be adamant about your views. Listen to others and accept that there is…

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 higher authority. It's essentially the scientific method. It does not mean you should agree with other peoples' opinions just because they said it louder and/or more often than you did.

I've witnessed senior engineers and managers misunderstand this mantra and (mis)use it to punish ICs who disagreed with ideas of other more/tenured engineers but lacked evidence for being "better".

If you intend to use this framework as a value in your organisation, make sure you and everybody else understand what it means (_especially_ your engineering managers).

Post reply on HN