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

91–100 of 155 posts

Re: Show HN: A Senior Engineer's CheckList

#91

Post by icebraining »

littleblah wrote: post #63
arcticbull wrote: post #61

These are excellent, except for one, which is to avoid politics. Politics is the art of making other people want the things that you want. If you can't do that, you're not a senior engineer. Politics is critical for your success, and honestly, a large number of these sixty points fall under, IMO, politics. tl;dr: s/"Avoid politics, but have right folks vouch for your work"/"Become an adept politician".

> Politics is the art of making other people want the things that you want. I would say tactical negotiation and leveraging personal connect is healthy, but manipulation for personal gains at the cost of a larger good is what is my definition of "politics". I have seen couple of managers in my career who, while were poor managers based on employee voice surveys in the company, ended up with large charters due to bein…

> manipulation for personal gains at the cost of a larger good is what is my definition of "politics".

I think that's an unhelpful definition; one should avoid conflating the activity with a particular goal. Politics is governance and decision-making, and how to convince people to support your position; whether that's performed for personal gain, or for the good of the company, or for the good of society (and the three are not mutually exclusive), is another thing.

Re: Show HN: A Senior Engineer's CheckList

#92

Post by icebraining »

siquick wrote: post #15
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?

None of that matters if employees aren't getting paid.

Being a prerequisite is not the same as being the only thing that matters. Also, the company making money does not mean the employees will get paid.

Re: Show HN: A Senior Engineer's CheckList

#93

Post by jcadam »

dagw wrote: post #74
xxpor wrote: post #70

Earlier quoted context omitted.

I wonder where people work where they can become a senior engineer in the first place without getting involved in hiring.

I've been a "senior" engineer for years, in that time I've read through a few dozen CVs, sat in on 2 interviews, and had final say in hiring of exactly zero people. I suspect the same is true for at least half the senior people here, unless they also happen to managers.

I remember myself and every other senior engineer on a team once rejecting a candidate and being overruled by management. The guy was hired and... turned out to be as useless as we thought he'd be.

Re: Show HN: A Senior Engineer's CheckList

#94

Post by icebraining »

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…

People generally don't want the company to lose money either. Many ethical and even law violations happen for the same reason you gave: they don’t stop to think about it. Ethical and legal consequences are not always obvious.

Re: Show HN: A Senior Engineer's CheckList

#95

Post by littleblah »

icebraining wrote: post #91
littleblah wrote: post #63

Earlier quoted context omitted.

> Politics is the art of making other people want the things that you want. I would say tactical negotiation and leveraging personal connect is healthy, but manipulation for personal gains at the cost of a larger good is what is my definition of "politics". I have seen couple of managers in my career who, while were poor managers based on employee voice surveys in the company, ended up with large charters due to bein…

> manipulation for personal gains at the cost of a larger good is what is my definition of "politics". I think that's an unhelpful definition; one should avoid conflating the activity with a particular goal. Politics is governance and decision-making, and how to convince people to support your position; whether that's performed for personal gain, or for the good of the company, or for the good of society (and the thr…

fair enough

Re: Show HN: A Senior Engineer's CheckList

#96

Post by mgkimsal »

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 and looked at the screen, and it was there. HOWEVER... after the midnight job run, the data was gone. No one ever looked the next day. Until October, and then it was way too late.

The whole "respect the existing code" has a HUGE assumption in it - that things are actually WORKING CORRECTLY in the first place. It also often assumes some of the original people who wrote the code you're dealing with are still on the team and and to answer questions.

THAT particular project above - my gut was "rebuild" - and we didn't. 16 months later, we are still finding code that is simply broken - data is lost, things are breaking, etc. But the whole "well, you're just someone coming in new - all devs just want to start from scratch and you shouldn't do that!" reared its head, and that idea was pushed aside.

I'd turn it around. Someone needs to be able to demonstrate - usually via automated tests I'd think - that things are, in fact, working as expected/assumed. If not, study/understand, then feel free to rebuild/throwaway.

I've taken part in another project with hundreds/thousands of tests, and while I hit code that looks/smells weird sometimes, some of the original people are on the team still, answer questions about 'why', and the tests pass. Even though it sometimes looks 'bad', it's functional and we can demonstrate its functional and working.

This is a HUGE difference, and that assumption about "it's working correctly right now" shouldn't be taken for granted.

Re: Show HN: A Senior Engineer's CheckList

#97

Post by SMFloris »

arcticbull wrote: post #62
avip wrote: post #46

It's a (thoughtful) list for the "senior engineer in 500+ heads company". If you work for a small startup (where you'll be forced to be "senior engineer" if you like it or not), you'll have no "manager", "peers", "projects", "hiring", "mentoring", "networking", and so 95% of the list items immediately pop.

If you're at a startup you better be hiring! That's your #1 job! You better keep that bar high because the next round of folks will be hired by them. Further, at a small startup you can't get away from a bad hire, they're literally adjacent to you for 50+ hours a week. Further to this point, networking is crucial too, but it's more networking outside the company. With other startups, with other technical folks -- you…

As the CTO of a small-ish startup, this rings so true. All our employees were hired from our network. Its only now that we'll look for other sources to benefit or hiring pipeline.

Re: Show HN: A Senior Engineer's CheckList

#98

Post by richardwhiuk »

imafish wrote: post #57
ben_jones wrote: post #9

Earlier quoted context omitted.

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?

A mechanical engineer with A junior web developer, with less than 1 years experience might have spent two days reading https://www.amazon.co.uk/Sams-Teach-Yourself-PHP-Hours/dp/06... (if that).

Let's not pretend those are the same.

Software Engineering has a history of trashing any benefits of formal education, and refusing to believe that any of it has any worth.

Re: Show HN: A Senior Engineer's CheckList

#99

Post by iovrthoughtthis »

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…

I find that things I think would be easy and often incredibly difficult for people who are not as experienced as I am. That certainly played out while I was writing exams for undergraduates.

Once we become experts (relatively) at something it becomes very difficult to judge "easy" and "hard" things. I suspect we have rose tinted glasses about our prior selves and their ability. Plus, the people we are testing are not our prior selves and have a totally different set of experiences they draw from.

You're comment feel very much so "back in my day" which I am almost certain is a logical fallacy.

Re: Show HN: A Senior Engineer's CheckList

#100

Post by DarkWiiPlayer »

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…

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.
Post reply on HN