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

281–290 of 290 posts

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

#281

Post by rswail »

1. Understand that Software Engineering is not a discipline yet. There are some foundational elements, but the field is less than a century old.

2. Think in the abstract. Implementation details are just that, details.

3. Ideas and concepts can be reused, code reuse (in business logic areas, not technical support) is rare.

4. "Design is about constraints" - Charles Eames

5. Understand the foundations, finite state machines, what REST as a style actually means, why Nouns are more important than Verbs, don't reinvent things...

6. Learning never ends.

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

#282

Post by adampk »

ma2rten wrote: post #266
adampk wrote: post #262

An opinion from a Product Manager: When you truly "trust" the engineer. You know their opinions are honest and well thought out. They do not have junior dev energy of saying "two days!" optimistically and not old beard energy of "it can't be done, you won't be able to launch it". "Master" really is a great word for it, you have complete faith in the individuals word.

This means they never work on things they have not worked on before.

I am not sure that it does. Honestly responding with "I haven't tried that before" seems to be harder than it sounds.

I would trust a master to take the appropriate amount of time to do a research spike or to bring in the right people in and understand how to get going.

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

#283

Post by robertlagrant »

disgruntledphd2 wrote: post #242
robertlagrant wrote: post #200

Earlier quoted context omitted.

If you have a load of smart engineers, sometimes it can be a more successful strategy to just build something than to pay EY £250k to do market analysis, get a load of execs bought in who then will "make it work" even if it shouldn't, or kill it off even if they shouldn't, and then finally get a committee-written spec handed over to be built in a rush.

Sure, there are pathologies at both ends of the spectrum. I do think it's worthwhile (particularly here), that software engineers/technical people are subject to their own set of development pathologies.

That's fair, yes.

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

#284

Post by conductr »

asdffdsa wrote: post #253
conductr wrote: post #147

Earlier quoted context omitted.

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

The most difficult hurdle is that there's never that direct communication between the finance guy and the tech guy. Projects tend to get lost in translation, where you have multiple layers of departments and emails and roles playing telephone. If an organization can have that direct finance-to-tech guy/gal link, it would be the most effective way to provide the most effective value imo.

It’s definitely a problem worth focus. I recommend networking with some of the finance folks. It’s as simple as a lunch meeting, ask them about some of the projects that are in planning phase, offer your assistance. You’ll have to figure out what is the post-COVID equivalent.

I find some in finance and IT get along fairly well and can build a bigger rapport fairly easy. We’re all excel nerds and many of us have taught ourselves how to program to an extent (VBA, etc).

Depending on the organization, we tend to be more focused on leadership support. A junior analyst will get much more face time with VP and up than down. So that’s part of the problem is those connections just don’t always exist. When they do, it might be with an IT director which has maybe become too far removed from codebase or implementation challenges. It happens with every department within the organization, not just IT. My experience is outside the software industry so may work a little different if sole function of the company is software.

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

#285

Post by natenthe »

arensc wrote: post #62
natenthe wrote: post #61

Earlier quoted context omitted.

Is this a parody?

I realized something while explaining this, it might be intractable to explain other than to just use basic blanket statements lol

LOL. I think your GPT-3 needs some more training.

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

#287

Post by gofreddygo »

arcticbull wrote: post #142
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.

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…

Therein lies a catch.

In your analogy if I get really good at getting stuff passed through city council, what would I optimize for ?

A: Building better bridges ?

Or B: building better money making bridges (potentially of of inferior quality) ?

I'd bet there are more takers for B. And at that point we now have better city council optimizers than better bridge builders.

Lets say we now make a team of some folks from both groups. Now who's going to able to get more people onboard their plans? Its the city council optimizers again. And now some bridge builders figure it out and become better optimizers than builders.

We then take it a step further and add competing teams. Same thing repeats. The team better at city council optimizing beat the better builders all the time.

In this whole process its the quality of the bridges that stays the same ( in most cases it goes down) and the costs of it keep going up.

My sad, unfortunate observations in the field.

Love to see a way out.

Edit: in this way of thinking , the assumption is that there are higher chances of making more money from poorer quality bridge than a more advanced, higher quality bridge. One exception to that is the strategy where you first provide better bridges at lower cost and then bump up the prices for maintenance.

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

#288

Post by varikin »

MaxBarraclough wrote: post #214
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.

> Creating a data schema (sql, no-sql, api based, whatever)

Schemas apply to more than databases. That may be less important for drivers, where the developer is also the domain expert for what they are implementing, but not necessarily so for avionics software. Lets saw you are implementing a black box. Are you the developer also a flight expert that knows everything that needs to be recorded and how each data point relates to each other? Not just in the sense of the hardware, but everything an FAA investigator wants to know. Probably not. So you need to work with pilots, FAA, and other non-developers to understand that domain.

Knowing how to construct a data model by talking to the experts of that domain is not just for databases.

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

#289

Post by vram22 »

vram22 wrote: post #275
conductr wrote: post #147

Earlier quoted context omitted.

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

Here is another example of a project or feature users did not use at all, or used less than was expected / wished for. This one is from a Google Talk:

Watch "The Effective Engineer | Edmond Lau | Talks at Google" on YouTube https://youtu.be/BnIz7H5ruy0 - at about 3:21 in.

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

#290

Post by permille42 »

rramadass wrote: post #274
permille42 wrote: post #271

Earlier quoted context omitted.

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…

There is a big difference between what you communicate broadly as a public figure and random comments under a throwaway.

Linus has said many attacking things publicly under a position of authority.

What I say here bears no weight because if what I say is disliked I am simply downvoted and dismissed.

I disagree that being offensive solves anything. I am fine ( as you've pointed out ) with being extremely offensive and attacking the shit out of anyone I see fit, but I don't think it is particularly effective or a quality trait.

Anytime you say things in an offensive way, you are intentionally being hurtful. This is not a good thing, and I don't think is justifiable.

My doing it in no way makes it right, nor invalidates my judgement of those who make similar statements to a broad audience.

Consider the effect of me ranting here. No one is going to go: "Wow I'd better pay attention to what permille42 says he is an expert. He must be attacking people for a good reason."

Nope. Anytime I rant most readers will just immediately dismiss everything I said, mostly because my tone tends to be so aggressive. I don't think such people are wrong to dismiss as such aggressive statements do tend to be from people who are offbase and don't know what they are talking about...

Post reply on HN