How many times a year do they have to wake up in the middle of the night to fix something broken?
Ask HN: What does mastery look like in software engineering?
141–150 of 290 posts
Re: Ask HN: What does mastery look like in software engineering?
#142I’ve been pondering this a lot lately, as an engineering leader. Masters in my organization have an extremely high ratio of value shipped to hours worked. This means two things. They are able to discern and avoid work that does not provide value (this is often their greatest skill), and the best ones can direct a whole team away from large swaths of work that is not valuable. And they are able to build systems such t…
I don't disagree with this, but sadly, a prerequisite for that is a position of privilege where you're able to push back against non-valuable work. I've seen many, many very good software developers that have this quality, but get overruled, and their true value goes unrealized as a result.
Part of what it means to be a senior engineer is that you have a mastery over the soft skills/people skills commensurate with your engineering abilities. Someone who knows how a bridge should be architected but cannot navigate the politics of city council necessary to get it built isn't much of a bridge builder.
The importance of good politics cannot be understated. Politics in this case is roughly defined as getting people onboard with your plans.
Re: Ask HN: What does mastery look like in software engineering?
#143I’ve been pondering this a lot lately, as an engineering leader. Masters in my organization have an extremely high ratio of value shipped to hours worked. This means two things. They are able to discern and avoid work that does not provide value (this is often their greatest skill), and the best ones can direct a whole team away from large swaths of work that is not valuable. And they are able to build systems such t…
I don't disagree with this, but sadly, a prerequisite for that is a position of privilege where you're able to push back against non-valuable work. I've seen many, many very good software developers that have this quality, but get overruled, and their true value goes unrealized as a result.
If you think something does not produce value and you have knowledge to back it up (you could think something is of no value if you don't know the big picture), and you are "forced" to do it anyway, then it all depends on pay. If you get a lot of money for this, you can exchange these later to fill any gaps that this will create or simply leave the co, unless you want to be known for doing fool's errands and stroking managers egos.
Re: Ask HN: What does mastery look like in software engineering?
#144Earlier quoted context omitted.
I don't disagree with this, but sadly, a prerequisite for that is a position of privilege where you're able to push back against non-valuable work. I've seen many, many very good software developers that have this quality, but get overruled, and their true value goes unrealized as a result.
This happens to me at my organization fairly often. I build solutions I'm asked to build and then an abusive architect coopts that work and rewrites it in a shitty, unusable way. Users cry at me, but when I tell them what happened, they are silent. No one cares enough to cry to leadership. And the leadership have clearly said they have no intention of overruling what said architect talks about.
Sounds like trauma bonding. I'd leave yesterday unless there is a bad market.
Re: Ask HN: What does mastery look like in software engineering?
#145 - Sqlite
- Symfony framework
Re: Ask HN: What does mastery look like in software engineering?
#146Earlier quoted context omitted.
I don't disagree with this, but sadly, a prerequisite for that is a position of privilege where you're able to push back against non-valuable work. I've seen many, many very good software developers that have this quality, but get overruled, and their true value goes unrealized as a result.
If you think something does not produce value and you have knowledge to back it up (you could think something is of no value if you don't know the big picture), and you are "forced" to do it anyway, then it all depends on pay. If you get a lot of money for this, you can exchange these later to fill any gaps that this will create or simply leave the co, unless you want to be known for doing fool's errands and stroking…
Almost agree. I would say that if this is the case, Pay is local optimisation.
On the long run, if you stay in such a company your market value will by reduced as it is
(a) psychological very difficult to resist such culture to influence your mind, unlimitedly transforming you.
(b) will eventually turn your life into a saga of bitterness and resentment, lower self esteem.
(c) arguably, such a company will ultimately fail in their business.
so you're probably better off take a possible temporary pay reduction for a better happiness and higher pay on the long run.
Re: Ask HN: What does mastery look like in software engineering?
#147Earlier quoted context omitted.
I don't disagree with this, but sadly, a prerequisite for that is a position of privilege where you're able to push back against non-valuable work. I've seen many, many very good software developers that have this quality, but get overruled, and their true value goes unrealized as a result.
Part of what it means to be a senior engineer is that you have a mastery over the soft skills/people skills commensurate with your engineering abilities. Someone who knows how a bridge should be architected but cannot navigate the politics of city council necessary to get it built isn't much of a bridge builder. The importance of good politics cannot be understated. Politics in this case is roughly defined as getting…
While your bridge analogy is true, I feel it's even more valuable to have an informed view for what's on the other end of that bridge. If you work the politics and use all the right materials to build an efficient bridge that's great. But a wonderful bridge to nowhere is still a bridge to nowhere.
I say this because as a finance guy, I've been on lots of projects that look great on a spreadsheet and marketing, sales, or somebody else is really pushing for the investment. That's the point where a technical person takes over and builds what's asked, or a really great technical person may ask a few questions and raise a few points nobody else considered and the whole bubble bursts as we realize it's not feasible/or we can test it in a certain way before investing big time/money into it.
Probably not mastery of SE as OP asked. But mastery as a business partner within an organization.
Re: Ask HN: What does mastery look like in software engineering?
#148Earlier quoted context omitted.
I don't disagree with this, but sadly, a prerequisite for that is a position of privilege where you're able to push back against non-valuable work. I've seen many, many very good software developers that have this quality, but get overruled, and their true value goes unrealized as a result.
This happens to me at my organization fairly often. I build solutions I'm asked to build and then an abusive architect coopts that work and rewrites it in a shitty, unusable way. Users cry at me, but when I tell them what happened, they are silent. No one cares enough to cry to leadership. And the leadership have clearly said they have no intention of overruling what said architect talks about.
[deleted]
Re: Ask HN: What does mastery look like in software engineering?
#149I’ve been pondering this a lot lately, as an engineering leader. Masters in my organization have an extremely high ratio of value shipped to hours worked. This means two things. They are able to discern and avoid work that does not provide value (this is often their greatest skill), and the best ones can direct a whole team away from large swaths of work that is not valuable. And they are able to build systems such t…
> They are able to discern and avoid work that does not provide value (this is often their greatest skill) junior dev here...could elaborate a little on what this means? Generally speaking the PM is the one creating a roadmap and informing what is the highest value item to work on. I must be misunderstanding what you're referring too.
As stated by a previous head of product, great senior engineers can choose to switch jobs and instantly become a great PM.
Re: Ask HN: What does mastery look like in software engineering?
#150Not sure about software engineering, but if I have seen anyone absolutely master anything "programming" related, it'd be Martin Shkreli. The programming environment: Microsoft Excel.