Mastery in Software engineering is the ability to conceive and design a program or app in ones mind and then build it and have it work flawlessly. In my experience when a company wanted something done they set up a small team offsite with little corporate oversite. This is why small startups drive innovation. Simplicity is genius and is often seen by users as magic.
Ask HN: What does mastery look like in software engineering?
241–250 of 290 posts
Re: Ask HN: What does mastery look like in software engineering?
#242Earlier quoted context omitted.
It depends on the organisation, to be honest. For instance, in my experience at a FAANG, the issue was often that a new technical solution was proposed, architected and built before any business/market people got involved with the result that loads of amazing, brilliantly architected and completely useless projects got built. (My favourite time was when a (really smart, to be fair) software engineer rediscovered the…
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.
Re: Ask HN: What does mastery look like in software engineering?
#243Earlier 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.
Absolutely. Touch typing is a game changer, not only because with practice, you can just think the code and see it appear on screen, but because you no longer have to glance at the keyboard and your full attention is on the code.
Re: Ask HN: What does mastery look like in software engineering?
#244Actually coding something is the last resort.
Re: Ask HN: What does mastery look like in software engineering?
#245I’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.
It's very easy to get distracted as a developer on something that adds little to no value. You will do this repeatedly throughout your career. Try not to :)
It may also depend how much you're micromanaged vs. picking your own path. Sounds like you're saying none of your work is self directed, and you don't participate in design decisions yet?
Anyway, even if you don't have much say there's still ways to direct your work. You can push back against whatever is demanding the low value work.
Re: Ask HN: What does mastery look like in software engineering?
#246Ultimately where you want to be with soft eng. is where you can produce and deliver value, regardless of mastery. That includes communication and steering of projects to value
Re: Ask HN: What does mastery look like in software engineering?
#247Earlier 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.
Not writing from scratch, and not what I consider "nice" code (specifically avoiding the term "good" here). There are plenty of cases that wind up being typing jobs essentially. Usually, that means you're not really designing code as you write, though.
Re: Ask HN: What does mastery look like in software engineering?
#248In my experience it means you rarely write software but you've moved into architecting software platforms and telling other people how to write software. I'm just a devops guy but my current project is like that, where our lead architect has really impressed me by drawing up the design of a very scalable system. My task is merely to implement and manage kubernetes for it and we have other devs who are using java, .ne…
If you rarely write software then you are not moving towards mastery in engineering it. There is no such thing as a master painter who is primarily a manager of painters. You can be a masterful manager, can deliver much more value than a single programmer, etc. But the engineering of software occurs primarily in the thinking about and directly working on it in its specifics.
Jeff Koons likes to think he is
Re: Ask HN: What does mastery look like in software engineering?
#249I don't think there is mastery in this work. I've been doing this for decades, and I still think my code from 6 months ago is crap, no matter how much I learn and improve. Mastery would imply that you can do it all, and do it right, on any project, and there is just too much change and evolution for that to ever be true. My goal is simply that I continue to improve.
Crap how? Is there mountains of commented out code, dead code, and misdirection? Has the code been adequately tested? Do you use appropriate code analysis tools (lint ect.), to enforce the above. Still having nitpicks in the code, questionable design, lines that could be eliminated, ect. is different from sloppiness and having no clue how to address these issues.
Re: Ask HN: What does mastery look like in software engineering?
#250Something that makes sense to the next developer without too much effort (assuming that it works).