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

Ask HN: What does mastery look like in software engineering?

news.ycombinator.com

Post reply on HN
Print view View original

211–220 of 290 posts

Re: Ask HN: What does mastery look like in software engineering?

#211

Post by intricatedetail »

guytv wrote: post #146
intricatedetail wrote: post #143

Earlier quoted context omitted.

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…

All valid points!

Re: Ask HN: What does mastery look like in software engineering?

#212

Post by rramadass »

abdabab wrote: post #106
rramadass wrote: post #95

Earlier quoted context omitted.

Can you please link the talk?

It’s this one: https://www.ted.com/talks/linus_torvalds_the_mind_behind_lin... . The code he referred is here: https://github.com/mkirchner/linked-list-good-taste

Ah; i had seen the TED talk earlier though i had not looked at the code example in detail.

Thanks for the links.

Re: Ask HN: What does mastery look like in software engineering?

#213

Post by davewritescode »

stonecharioteer wrote: post #132
bedobi wrote: post #122

Earlier 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.

Leadership puts an architect in place because they don't have the time to care about code level details. I would personally mention it to leadership but frame it in a way that your work is being rejected but nobody is explaining to you why so that you can learn and do better next time.

Unfortunately in a large software engineering organization tact and political savvy is more important than raw engineering skill. Once you've been in the industry long enough, you'll understand it.

One of the problems that's common in organizations is that most of the work at the junior level is highly focused on individual contribution and that completely flips at some point in your career.

Re: Ask HN: What does mastery look like in software engineering?

#214

Post by MaxBarraclough »

varikin wrote: post #50

I recently got a masters in software engineering, not that this means I've mastered the discipline, but I think it set a decent idea of what is important. Here's a incomplete list of topics that I is worthwhile: Creating a data schema (sql, no-sql, api based, whatever). This seems simple and obvious, but it becomes very hard very fast, especially when you need to model a complex subject that you know nothing about. C…

Your point about databases strikes me as domain-specific. If you write high-performance game engines, or avionics software, or drivers, I imagine you could go your whole career without encountering a conventional database.

Re: Ask HN: What does mastery look like in software engineering?

#215

Post by narag »

mechEpleb wrote: post #182
Cthulhu_ wrote: post #174

Earlier quoted context omitted.

It reminds me of a guy I used to work with. He two-finger typed looking at his keyboard all the time, but the code he did end up writing was exactly what was needed. Consistency and quality was much more important than cold, hard "productivity".

Can anybody actually produce working code at the same pace as they touch type? Typing hardly registers as a factor when it comes to how long it takes for me to code anything, at least.

Can anybody actually produce working code at the same pace as they touch type?

I can. Actually, when I learned touch typing I realized how much was I slowed down by typing before.

You might argue that I need to think for a time before I start typing. That's right. But:

1) Once I start, it flows and it's like I'm reviewing the code as I type, correcting and expanding.

2) Writing fast somehow makes me think faster for the next "pre-typing" thinking cycle.

Re: Ask HN: What does mastery look like in software engineering?

#216

Post by rramadass »

still_grokking wrote: post #121

https://faculty.washington.edu/ajko/papers/Li2019WhatDisting...

Excellent, Great link and Thank You !

This answers the OP's question exactly; a proper empirical study on various dimensions of attributes.

Everybody here should read this.

Re: Ask HN: What does mastery look like in software engineering?

#219

Post by mixermachine »

ZephyrBlu wrote: post #173
mkinsella wrote: post #110

Earlier quoted context omitted.

This is the biggest difference between a Junior Engineer and a Senior (or Staff Engineer). A Senior Engineer knows what the highest-value work is and is influencing/driving the roadmap. A Senior Engineer says 'no' more often than 'yes' and backs it up with a 'why.'

It's kind of a self-fulfilling prophecy though. Most Seniors are driving the roadmap simply by virtue of being a Senior, and most Juniors have no opportunity to influence the roadmap because Seniors control the decisions. Of course ideally everyone can contribute, but I think that's relatively rare.

If the structure of a work place is very strict, then yes this is 100% true.

I how ever could already experience a more open scrum process in which we all have a say.

For me it all started in an university project with four (incl me) people. I denied a good portion of the requests my supervisor gave me there, not because they were bad, but because they simply did not fit into the time budget or were not realistic. She was actually very happy about that because she was not that tech savy back then and learned a lot threw the process. Very good experience for me and we finished the project on time and exceeded expectations.

Re: Ask HN: What does mastery look like in software engineering?

#220

Post by narag »

Cthulhu_ wrote: post #174
itsmejeff wrote: post #85

I’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…

It reminds me of a guy I used to work with. He two-finger typed looking at his keyboard all the time, but the code he did end up writing was exactly what was needed. Consistency and quality was much more important than cold, hard "productivity".

Enter the Dragon

-- Do I bother you?

-- Don't waste yourself.

-- What's your style?

-- My style? You can call it the art of fighting without fighting.

-- The art of fighting without fighting? Show me some of it.

Post reply on HN