Live data from Hacker News

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

news.ycombinator.com

271–280 of 290 posts

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

#271

Earlier quoted context omitted.

As an "uncontrolled lunatic" myself, they are rather obvious in the field. I'll agree that many of the things he says are reasonable. An example is his recent defense of long lines and dismissal of the insane "80 characters per line" peeps. What I mean specifically by "uncontrolled lunatic" is that he often ignores convention and current opinion and does and says things that get him into trouble. He also has a temper…

I have heard these arguments before. You cannot separate Linus' so-called "shortcomings" from how they were instrumental in getting him to what he has delivered and where he is today. Genius cannot be constrained by every single artificial social more and etiquette; we are Humans not Automatons. As long as they do not lead to destruction of product/project/self/others it is merely a character trait which makes the pe…

I disagree. The notion that "you have to accept the arrogance and obnoxious attitude of high level software engineers because it is inevitable that the type of people who excel at creating software are that way because they don't focus on social skills". Every one of us can work to be more polite and caring of the emotions of others. Especially if you know you suck at it you ought to use effort to be better in that way.

Justifying treating others poorly just enables more people being hurt. We should not reward people for this sort of behavior. Turning a blind eye to it because "they are great software engineers" is not right.

Your comment treads very much into the "for the greater good" mentality where you can justify anything based on the results.

"Unique character trait" my ass. Obnoxious aholes are just that. Obnoxious aholes. They need to fucking stop and be more kind.

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

#272

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…

Essentially avoid downstream defect correction

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

#273

Earlier quoted context omitted.

I fail to decrypt who TJ can be

TJ Holowaychuk, who has written some of the most popular Node.js libraries. Express.js is probably the one most have heard of. He now operates in the Go space in which I presume he also has some influence as well for OP to bother mentioning. I would say that his handiwork in crafting good libraries was a significant reason that Node took off like it did so quickly. This article from 2014 highlights just how many libr…

> article [by @kelas is all about] how good he as at writing them

funny to see how this is still relevant.

i'm sorry to say, but anyone who read this ancient piece at least marginally past tl;dr would know that your conclusion can't be more false (must be due to my poor command of your language, sorry about that.)

i originally wrote this text in response to eponymous question on quora, which saw some unexpected gargantuan success with 100k+ views in the first year or something like that.

tj said "meow" under that quora answer, and disappeared for good - while i was left exposed to some really agitated tech bloggers who wanted an interview about how did i get so smart to figure out that the entire headless chicken called node community was just brutally duped.

no such interviews could be granted, but in wake of the story some people bothered to look for the clues in his gh activity - mostly frequency analysis of "his" commit logs in a galaxy of repos. this is why most tj's repos were promptly republished elsewhere after that.

bottomline: the article says that tj was a SCAM, so there's that.

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

#274

Earlier quoted context omitted.

I have heard these arguments before. You cannot separate Linus' so-called "shortcomings" from how they were instrumental in getting him to what he has delivered and where he is today. Genius cannot be constrained by every single artificial social more and etiquette; we are Humans not Automatons. As long as they do not lead to destruction of product/project/self/others it is merely a character trait which makes the pe…

I disagree. The notion that "you have to accept the arrogance and obnoxious attitude of high level software engineers because it is inevitable that the type of people who excel at creating software are that way because they don't focus on social skills". Every one of us can work to be more polite and caring of the emotions of others. Especially if you know you suck at it you ought to use effort to be better in that w…

You are now reading things which were simply not said nor implied.

It is also quite ironic that while you talk about "being nice/kind" your posts are the ones containing inflammatory phrases like "uncontrolled lunatic", "arrogance and obnoxious attitude", "my ass" and "obnoxious aholes" !

Coming back specifically to Linus, he has never been any of the above. He has been direct and harsh when needed (there is a world of difference between this and the phrases you have used), otherwise he has shown a lot of restraint. For example, he has said that due to the nature of email communication, one has to be direct since a lot of non-verbal and personal nuances cannot be conveyed which is exactly right.

I am sure we can all recollect email chains/discussions/meetings where nothing was ever achieved because people did not want to offend somebody with thin skin in spite of the fact that they were squarely to blame. Being direct and calling them out is not being obnoxious/arrogant but simply moving things along towards a goal. To be nice/kind does not mean everybody has to be mollycoddled and tip-toed around due not wishing to "hurt their feelings". Engineering is a hard science and while we have to follow social mores and etiquettes this should be regulated (i.e. we should know when to break them) so that progress towards the end goal is not derailed.

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

#275

Earlier quoted context omitted.

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,…

Good one. Another on the same lines, and also related to your parent comment's point about politics, is:

Getting the users in the org to, you know, actually use that well-specced, well-built project, which was delivered within time and budget (or with only a small overrun). I mean, use it at all, or use it enough for it to deliver its benefits. Real life issue. Seen it on at least a few projects I've worked on, including two early in my career. Inertia, luddite fears, turf wars can be some of the causes.

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

#276

Earlier quoted context omitted.

Totally agree and I wish to those people to leave the place they are currently in and find a better where their skills are truly recognised.

There's another facet to this which I think is far more important that OP question of "What [exactly] does mastery 'look like'?". The more important question is "how do you cultivate mastery?" How does your organization get to a place where people can develop mastery instead of the organization trying to create it instantly by hiring "the right people"? Regardless of what people may claim, hiring is not a solved prob…

Great point. Seen some of the things you describe, in places where I worked.

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

#277
Ability to: Start small with a shitty demo which can get buy-in from other folks on a team and continue pounding out high-impact features in no time first, to sell the invention to anyone. Then get this demo cleaned up to the point it ships with docs, tests, telemetry in production, and there are no bugs and crashes. Just couple of improvement requests. And when this thing can be enabled/disabled dynamically, and enhanced/expanded for the future without major rewrites.

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

#279
post #254

Look no futher than this: https://archive.is/NCWmz (Wolfenstein 3d iPhone development By John Carmack, Technical Director, Id Software) To be exact: "The developers came back and said it would take two months and exceed their budget. Rather than having a big confrontation over the issue, I told them to just send the project to me and I would do it myself. Cass Everitt had been doing some personal work on the iPhone,…

Not doubting his greatness, but It's definitely a lot easier to be motivated to work harder and faster when it's your own idea/project. I assume for the team of developers it was just another project their employers were asking them to work on, with all the expected nonsense (rituals) that come with it, and so why would they want to bust a gut / work 20 hour days / care more than they are being paid to care, to get i…

I agree with you, but judging by the whole article the main thing here was probably the same old story with outsourcing company either wanting to bill extraordinary amount of hours or employing novice to medium developers for the project but charging full senior price for them.

I guess that for most of the guys, if they had opportunity to work on something with Carmack or Id Software in those days, it would be a priority to show yourself in best light and even work for free or heavily discounted price if needed to secure future deals. Especially since all source code was provided and basically the whole thing was just somewhat simple porting engagement.

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

#280
post #196
post #190

I don't think there is one answer but there are a few things I have noticed in my short career so far: * I think an intermediate level of mastery is when you realize that a computer is a logic machine built to serve humans and it will always listen to you if you're willing to put in the effort. You can always go a level deeper. Great engineers know all of the tools at their disposal and will bend the computer to thei…

> I think an intermediate level of mastery is when you realize that a computer is a logic machine built to serve humans and it will always listen to you if you're willing to put in the effort. You can always go a level deeper. Great engineers know all of the tools at their disposal and will bend the computer to their will if they need to. I've worked with some people who definitely seemed like "masters", and this was…

I only occasionally achieve this state but I find that it comes from high levels of comfort with the systems you're using. That's everything from the operating system to the programming language to your chosen editor/IDE.

When you have a high level of comfort with all of these things when you see a problem you can often guess *where* the bug is and that's half the battle right there.

Have you ever noticed that your friends will ask you to fix their WiFi or an app on their phone and even though you have no real expertise you can normally do it? That's a version of the same thing. You understand the general principles of the system and you're able to guess the general location of the problem and start flipping switches until it goes away.

Post reply on HN