Earlier quoted context omitted.
It seems like this value you brought in is "outside" the domain of software engineering, however. Yes, the solution ended up being found in software engineering, but the problem came from a business operation thing, no? (I wish you had gotten more thoroughly compensated for saving them a fortune.)
An engineer's job is to solve a problem creatively, not execute a rote technical procedure. The people who are just fed detailed instructions to execute are called "technicians" in the traditional industries. If you want to claim the title of an engineer, act like one. If all you can do is write code to spec, you are a technician.
Ask HN: What does mastery look like in software engineering?
261–270 of 290 posts
Re: Ask HN: What does mastery look like in software engineering?
#262"Master" really is a great word for it, you have complete faith in the individuals word.
Re: Ask HN: What does mastery look like in software engineering?
#263Earlier quoted context omitted.
It seems like this value you brought in is "outside" the domain of software engineering, however. Yes, the solution ended up being found in software engineering, but the problem came from a business operation thing, no? (I wish you had gotten more thoroughly compensated for saving them a fortune.)
Software engineering requires understanding enough of the reason behind requirements to know when the requirements could be simplified or should be augmented. I would even argue that understanding business needs and translating them into practice is the fundamental role of software engineering.
Re: Ask HN: What does mastery look like in software engineering?
#264To answer this question, one must first operantly define what mastery is. So what is mastery? To start, mastery is something on which one can be on the path towards, yet mastery is also a thing which has been achieved. So we need to talk about flow along a path and achievement of the objective.
PATH
The path to mastery is characterized by humility and child-like exploration combined with an intrinsic drive to integrate learning a and take paths that make individual sense to one on the apprentice’s path towards mastery. It is concerned with thoughtful action and adaptation. The ultimate focus is on the seeking of truth (an intrinsic reward) rather than and sometimes at the detriment to receiving external rewards (accolades, financial renumeration, and other materialistic artifacts). Such sacrifices and focus is made early in the mastery process and pay off once one inevitably achieves it. This is a pattern common in most individuals we would consider to be masters and the difficulty lies in staying on such a path despite internalized intuitions and the listening to an internal voice/drive pulling us away from society, the majority of who are not on the path at any given time. Mastery is high risk because it a deviant process often focusing on long term rewards rather than instant gratification or even short-term survival.
ACHIEVEMENT OF
What can a master do? Why is that beneficial?
Mastery is the seamless ability to fuse the intuitive with the rational while performing and understanding at a high level of competency in a given discipline or domain. It manifests as as such a deep internalization of a domain that one is able to spend cognitive effort on seamless cross-pollination between other disciplines, sculpting domains at will. Mastery is only achieved through embracing the humane, which means internalizing the fact that what makes us human is the blending of the rational (a step-by-step-step process) with the intuitive (a distributed and probabilistic process).
MASTERY IN SOFTWARE ENGINEERING
What is engineering? What is software? What commonalities do they share?
Given a definition of mastery, we see that the question of what engineering and software are next to be defined. These three questions should serve to form a foundation for discussion.
Engineering is the process of designing reliable processes and systems given constraints on resources, tools, and available thought patterns. It is also fundamentally concerned with risk management on the path to achieving an objective.
Software is a system which interfaces with either humans, machines, or both to achieve an objective. It serves as a medium for sending conceptual communicative signals across, within, and between various levels of abstraction to include physical computing done at the level of hardware.
As an aside, it must be stated that the delineation we place between software and hardware is an arbitrary though sometimes useful fiction to allow us to get tasks done. With this being stated, such a simplification is often over-used to our collective detriment.
The master software engineer understands hardware and software deeply at both the intuitiveness rational levels in order to design systems and process to specifications and with clarity to both machines and humans alike. This ability to provide and communicate with clarity is especially important when we consider that our colloquial models of machines themselves are over-simplified, a fact that one will quickly become aware of when trying to design applications across platforms that perform “low level” file system operations. In this case, it becomes apparent that even operations such as opening and closing files, tasks which one would think are stable and solved problems, have such variability that cross-platform development is more challenging than it should seem.
Not only does a master software engineer have the ability to communicate at different levels of abstraction of hardware and software—such a master also recognizes that communication is the operant word. Communication is signal propagation, filtering, and more, occurring at the personal, interpersonal, and organizational level as well. The master software engineer is seamlessly able to apply all principles of software development to psychological phenomena as well. To such an individual, there is no difference conceptually from a root pattern perspective.
Re: Ask HN: What does mastery look like in software engineering?
#265Earlier 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…
Hmm...why should the onus be on the engineer? An organisation that does this is broken. Most are. While it is important to realise that this brokenness is in fact widespread, I don't think it should be normalised.
Re: Ask HN: What does mastery look like in software engineering?
#266An 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.
Re: Ask HN: What does mastery look like in software engineering?
#267I’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…
Re: Ask HN: What does mastery look like in software engineering?
#268Earlier 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.
If I'm solving a hard problem (i.e. architecting a system or coming up with an algorithm) then 99% of my time is spent thinking rather than typing.
Re: Ask HN: What does mastery look like in software engineering?
#269Earlier quoted context omitted.
> 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.
I can give you an example from my career. We were building out a new webapp feature to deliver medical textbooks, which we had as xml documents direct from the publisher. Our customers, mostly large academic libraries and medical research companies, would get the electronic access to the books for much less than it would cost to get sufficient physical copies, and our cost for supplying the books would be minimal. A…
Re: Ask HN: What does mastery look like in software engineering?
#270Earlier quoted context omitted.
I think sometimes this means they do the unsexy stuff. For instance, having an easy build process, or understanding version numbers, or preventing an upgrade to this year's compiler.
Enabling the org to accomplish more with less (or keep it from falling into different pitfalls) is sexy. I feel it's a core part of my job to keep the rest of the eng team happy and producing value. A lot of times this comes down to seeing problems as they arise (ideally before them, but it gets harder to convince management of future issues if they haven't manifested yet).
that's a tough one, maybe the tough one.
It's hard to prioritize "trivialities" over features, especially when you haven't even given thought to defending the obvious.
Thankfully some of these things are being codified somewhere externally, say:
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...