11–20 of 155 posts
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.
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…
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…
The guidelines say that we should respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize.
The following quote could easily be interpreted as viewing software engineering as a subcategory of engineering:
> most of the items on this list seem broadly applicable to different types of engineers
Given that interpretation, it seems more like they expected an article like this to be about software-specific concepts.
How about ethics? company reputation? legal compliance? corporate responsibility?
> "Understand the business aspect of your work, and what makes money. Eventually, only that matters." How about ethics? company reputation? legal compliance? corporate responsibility?
> "Understand the business aspect of your work, and what makes money. Eventually, only that matters." How about ethics? company reputation? legal compliance? corporate responsibility?
'Checklist' made me think of something a little more task-focused, e.g. checklist for reviewing code, checklist for designing systems, checklist for deployment etc.
So... I love the content, but I'd change the terminology.
Here's my thoughts on a few of the items themselves:
"Follow the principles of extreme ownership." -- Unless the term "extreme ownership" describes something specific (like "Extreme Programming"), it should be reworded to clarify. What are these principles or what is 'extreme ownership'? Is it clearer to say "make sure you take ownership"? Or "don't waste time working on things outside of your domain"? Or "don't limit your focus to just those items explicitly owned by you"? The latter is approaching XP's "collective code ownership" / "shared code."
"Be reachable to other engineers" -- is this like making sure you're available? Like "check into the company Slack channel frequently"? "Make sure you reply-all to that 11pm email so everyone knows you were checking your email then?" Sorry: that sounds a bit cynical but it's easy to misread this principle that way. Best reword this one IMO.
"Avoid stretching yourself too thin to be effective" - this is a great tip but is it specific enough to be useful? How will I know when I've done this? I think I know the answer but would a junior engineer reading this list know?
"When dealing with politics, avoid it, but have right folks vouch for your work" -- this one is not specific enough for me. "Avoid politics"? Who are the "right folks" -- how would I know whether I had asked the right folks to vouch for the work?
"If you are under-utilized, ask your manager for areas to explore" -- IMO this works better if you can specifically say "I want to work on X" and bonus points if "X" is an item that you know contributes directly to high level goals for the company.
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…
Sometimes that mentor is you. It's good to know if that is explicitly expected of you in your role, because you will need to budget time to do it properly. It is an extremely important role for any team, so take it seriously too.
For project managers/employers reading, it is paramount that you make mentorship be part of the senior developer's roles. As your company grows, you will be churning through employees as new hires and as people leave. It is very easy to not notice that you just lost all of your domain knowledge because you thought everyone was on the same page, but actually you had your senior developers too busy to effectively spread the tribal domain knowledge.
Documentation is great, but there is nuance and depth to complex software decisions that can't be captured in text in a reasonable amount of time. Not only that, but you probably have less documentation than you think you do, no matter how much you asked for it. People don't read it either. They will sooner google a problem, or ask a colleague.
Some developers absolutely do not like the role because of the regular interruptions, I get it, but some people are more than happy to help be a go-to. It remains the favorite part of my job. Make it a question in your interview process so that you can make sure you have someone who is going to be happy making sure your domain knowledge is shared throughout the company.
> "Understand the business aspect of your work, and what makes money. Eventually, only that matters." How about ethics? company reputation? legal compliance? corporate responsibility?
...that's about it.