[HN Gopher] Ask HN: What does mastery look like in software engi...
___________________________________________________________________
Ask HN: What does mastery look like in software engineering?
When you think of someone who has mastered the discipline of
Software Engineering what comes to your mind?
Author : abdabab
Score : 344 points
Date : 2021-01-05 10:06 UTC (2 days ago)
| [deleted]
| corytheboyd wrote:
| Just rattling off some thoughts of my own
|
| * Consistent delivery of quality work
|
| * Instead of complaining about bad requirements that threaten
| system integrity, happily works with stakeholders to compromise
| on them accordingly
|
| * Can consistently describe every detail of every bit of work
| they have done, and answer any curveball questions about it too
|
| * Succinct and to the point, doesn't bog down meetings with
| tangential arguments and what-aboutisms
|
| Could probably keep going but that's good for now haha. I know I
| don't even satisfy all of these points myself at all times, but I
| certainly try to!
| mikewarot wrote:
| I heard a story that Dan Day - Rose Hulman class of 79, once sat
| down and typed in a complete system of programs and it worked the
| first time.
|
| Ward Christensen did it once as well, to the annoyance of my late
| friend Lloyd Smith, may he rest in peace.
| m3kw9 wrote:
| Ultimately 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
| permille42 wrote:
| "Who is John Galt?" Mastery could most closely be viewed as a
| state of enlightenment. To the non-enlightened it will appear to
| be dismissive and lazy.
|
| There are a variety of positions one could take once reaching
| enlightenment: 1. Domination. One could choose to be controlling
| of the entire field and use it for selfish benefit. 2.
| Dismissive. Once you reach the pinnacle it becomes apparent that
| both humanity and the society it has created are horrid and
| aren't worth interacting with. 3. Appreciation. One could choose
| to be thankful for being able to reach such a position and to
| respond by generously using the mastery to use it for the good of
| humanity. 4. Constructive Legacy. One could choose to form ones
| own group around that mastery to preserve it beyond themselves.
|
| I believe the dismissive position is the most reasonable and
| hence most likely to be chosen by those who reach true mastery.
|
| All four positions regularly occur and you can see it readily in
| masters of respective fields.
|
| The way a master appears depends on their reaction to having
| gained mastery.
|
| I think the dismissive position is also most likely because I
| believe there are far more masters than we ever notice. They are
| not noticed because the majority of them don't bother to use
| their mastery in an obvious way.
|
| Why should a master bother to correct those beneath them?
|
| If a master interacts with society they have an uphill battle to
| being treated with the respect they deserve. For the true master
| there is great value in going their own way and rejecting
| society.
| thelastinuit wrote:
| It reminds me of the Way of Tao
| kissgyorgy wrote:
| Uncle Bob Martin coined the term "Software Craftsmanship", you
| can watch his talks about the topic. I intend to follow it
| throughout my career.
| tomaszs wrote:
| Software engineering mastery occurs when a person brings donuts
| for everyone every single day.
| adampk wrote:
| 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.
| ma2rten wrote:
| This means they never work on things they have not worked on
| before.
| rcaught wrote:
| The code you don't write is more important than the code you do
| write.
| Bandrsnatch wrote:
| 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.
| one2know wrote:
| Que all the managers that will immediately list off 5 manager
| activities as software engineering "mastery."
| leowoo91 wrote:
| They're the ones who understand there's no silver bullet for all
| problems.
| smoyer wrote:
| That's an interesting question and I'm going to give you a
| somewhat snarky but truthful answer: Software mastery is
| exhibited by the code that I wrote today - and oh how horrible it
| is to look at what I wrote six months ago.
|
| Through-out my career, which is now over four decades if you
| include the software I wrote as a teenager (before I got paid to
| do it), I've continuously found a better, more elegant (which can
| almost always be read simpler or clearer) way to tell the
| computer what to do.
|
| So my non-snarky view-point is that there's no such thing as
| mastery but rather that it's the proverbial journey. There is
| however a baseline at the other end ... if it's not functional
| and maintainable, there's a definite lack of mastery.
| albertgoeswoof wrote:
| More likely that you a) overrate the quality of the code you
| wrote today (recency bias) and/or b) have forgotten the
| context/constraints that you wrote the code 6 months ago under
| anonytrary wrote:
| Ship more, talk less.
| paxys wrote:
| Being able to break a complex project into granular bite-sized
| tasks.
| rramadass wrote:
| See the paper linked in this thread by user "still_grokking"; it
| answers your question.
| thedevindevops wrote:
| Pai Mei mustache, sits on a rock meditating and dispensing advice
| to juniors, quotes Martin Fowler by heart, seems to never touch a
| keyboard but every commit will replace entire module(s)
| flawlessly, demonstrating high level architectural knowledge that
| lies on the far side of the organisation's learning curve.
| whatshisface wrote:
| > _but every commit will replace entire module(s) flawlessly_
|
| That's big commits, you're not supposed to do that. Masters
| commit individual characters that replace entire modules
| flawlessly.
| jgwil2 wrote:
| He squashes commits on merge.
| tachyonbeam wrote:
| Every module Pai Mei implements fits on a single page of his
| 80-column terminal, including comments. He manages this
| brevity not with obscure one-liners, but through algorithmic
| simplicity. Every module is precisely as complex as it needs
| to be to accomplish its purpose, no more, no less.
| barbarbar wrote:
| Pai Mei never deletes or modifies a single character. Every
| keystroke is perfect and can only be as it was initially.
| voxic11 wrote:
| He never said the commit will be big. He just said the commit
| will "replace entire module(s) flawlessly" which you seem to
| acknowledge can be sometimes done with as little as a single
| character.
| CoolGuySteve wrote:
| The Master does his job
|
| and then stops.
|
| He understands that the universe
|
| is forever out of control,
|
| and that trying to dominate events
|
| goes against the current of the Tao.
| dave_sid wrote:
| Hahahahaha. This is the funniest thing I've read on HN.
| girzel wrote:
| Having an accurate intuitive assessment of how difficult a task
| will be, and;
|
| knowing what to Google.
| 1vuio0pswjnm7 wrote:
| https://en.wikipedia.org/wiki/DONKEY.BAS
| lawwantsin17 wrote:
| Working knowledge of the whole hardware and software stack and a
| masterpiece to show it.
| varikin wrote:
| 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. Consider being hired by a hospital to model their
| records, or an insurance company. You need to talk to many people
| and understand how everything they say and do relates to
| everything else.
|
| Project management: You may not want to be a project manager, but
| you should familiar with scrum, agile, waterfall, lean, and
| kanban. At least you can have an informed opinion when you argue
| for or against how things are done.
|
| QA: You should know how to write a test plan for a large feature
| or application. This includes unit tests, manual testing,
| deciding what areas need more effort because getting it wrong is
| very bad and what is less important. This may include security
| and performance testing.
|
| Architecture and design: How would you design a new application?
| How would you add a new feature to an existing application? How
| do you communicate this design to a team or many teams?
|
| How to evaluate new things like languages, tools, libraries,
| technologies, etc. This isn't just reading a couple blogs, this
| is doing small scale test, proof of concepts, looking at the code
| to an extent, getting opinions for others you trust.
|
| Finally, communicating. Software engineering is a team sport. You
| need to know how to write design documents, test plans, maybe
| architecture plans, progress reports, etc. If you can't
| effectively communicate your designs, plans, or even why someone
| else's thing is bad or good, you won't be able to convince others
| that you are right. And remember, you need to not just convince
| your peers, but also non-technical people, such as managers, VPs,
| and many other.
| MaxBarraclough wrote:
| 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.
| ignoramous wrote:
| Not sure about software engineering, but if I have seen anyone
| absolutely master anything "programming" related, it'd be Martin
| Shkreli. The programming environment: Microsoft Excel.
|
| https://www.youtube-nocookie.com/embed/fASInVKShnM
| habosa wrote:
| 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 their will
| if they need to. At the same time, they know the difference
| between a great low-level solution and a shoddy hack.
| * Our industry is one of the few where we spend the majority of
| our time fixing our own mistakes. We call these mistakes "bugs"
| but they don't just appear, we produce them. The best engineers
| produce fewer bugs than they fix and rarely end up in a "whack a
| mole" situation where fixing one thing breaks another thing.
| J-dawg wrote:
| > _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 true of all of them. Quiet patience and
| an unshakeable belief that this thing is going to be fixable,
| even after trying multiple things that have gone nowhere. And
| they're almost always proved right.
|
| It also made me realise I need to get out of this business as
| soon as possible, because I'm the polar opposite. After a few
| failed attempts my brain goes into panic mode and the problem
| seems insurmountable. Then I "wake up" an hour later after a
| bout of procrastination, no closer to a solution.
|
| I often wonder about the chicken and egg of how people attain
| this state. Are they first and foremost technically brilliant,
| and the confidence emerges from that? Or is it more of a
| personality type that has allowed them to solve lots of
| problems and become technically brilliant along the way?
| olikas wrote:
| I had a similar experience early in my career. To me it was
| eye opening to see some masters keep investigating problems
| without getting emotional. I learned how not to care about
| the time it takes to figure things out, but to start and
| carry on. This way given enough time, almost all problems are
| solvable. The time pressure doesn't change this fact.
|
| In case of a time pressure, I just focus on workarounds
| instead of analysis. Once the problem is no longer burning,
| it's up to the project priorities to investigate the root
| cause.
|
| I also learned that panic never solved any of my problems, so
| when I notice that I am moving into panic mode, I stop for a
| minute and cool down. This is a skill that can be learned.
| Aeolun wrote:
| It's more a type of persistence I think. More junior people
| often ask me something along the lines of "How do you
| immediately know these things?". But the answer isn't
| anything magical. Generally one of:
|
| 1. I've run into the same or similar problem before.
|
| 2. I wrote the code that does this thing.
| bumbada wrote:
| The ability to master complexity.
|
| A master will be able to understand the relationship between
| systems so he can reduce combinatorial possibilities and reduce
| complexity to a minimum.
|
| In other words, a master will not shoot herself in the foot. She
| will also not let others shoot themselves in the foot.
|
| Then, depending on what you do, you will need technical ability:
| -Understanding basic physics or economics or whatever you
| interface with your software. -Understanding of low level systems
| (assembler and C) -Understanding of different paradigms(objects,
| functional) -Understanding of very High level systems (Lisp,
| Haskell) -Understanding of serialization(parsing and binary)
| -Understanding communications. -Understanding data handling.
| -Understanding interfaces(like command line, desktop or Web).
| -Understanding standards.
|
| But this depends on the particular work you need or want to do.
| You will be stronger or weaker in different areas.
|
| But complexity handling is common to any area in engineering.
| l0b0 wrote:
| Some acceptance tests for a software engineer:
|
| - Should know many tools to the level where they know their
| strengths and weaknesses. This allows them to select a useful
| collection of them for any new piece of work.
|
| - Should produce incremental project changes which all either
| improve the value or reduce the cost.
|
| - Should _balance_ all the improvements to produce useful,
| working software with a reasonable cost. For example, producing
| super-secure software with no useful features, featureful
| software with a bajillion bugs, or bug-free software with a
| gigantic cost are all bad.
| e9 wrote:
| How many times a year do they have to wake up in the middle of
| the night to fix something broken?
| forgotmypw17 wrote:
| story of mel.
| itsmejeff wrote:
| 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 that the cost of adding more value to the system remains
| constant as the system grows in complexity.
| hiimtroymclure wrote:
| > 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.
| DougWebb wrote:
| 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 problem came up. Many of the libraries were government
| funded, and required physical possession of any books they
| purchased. I was in a meeting with the c-level execs, sales
| directors, and pms, and they were planning out the cost of
| building an organization that would produce a cd-rom version
| of the textbook products. They were going to need a large
| team to manage creating the books on cd, and for managing the
| production and mailing of the CDs when orders were received.
| It was going to cost a fortune.
|
| I told them to hang on a minute: I'm already converting the
| xml for these books into html for display in the app. I can
| easily generate static html too, write it to disk, and
| generate an iso file, every time we publish a new book. Then
| I can add a download link in the webapp, and if they need a
| physical copy they can download and burn it to disk
| themselves. We'll include instructions. This will take me
| maybe an extra week, and we'll have no ongoing operational
| costs.
|
| I think I got a $50 Amazon gift card for that suggestion. Or
| maybe a Starbucks card.
| plutonorm wrote:
| You have to be present in the meeting. All the places I
| have worked - and I have worked in many over 15 years - do
| not allow this. You need to be in a startup to be close
| enough to have this kind of impact. Agile just makes this
| situation worse. It's incredibly frustrating to be see the
| value you can add, but having no ability to make it happen.
| mechEpleb wrote:
| Can't have pesky engineers with their pedestrian
| technical concerns mess with the business decision
| makers' thought process. A good engineer takes whatever
| the creative, smart visionary comes up with and
| implements it down to the smallest detail.
| hiimtroymclure wrote:
| Thank you for the story, I definitely understand now. I am
| also relieved that you were compensated for this critically
| important pivot! /s
|
| I am hoping this will be an area I can eventually excel in.
| I was a senior PM for a while and decided I wanted to write
| code instead. Been going down this crazy career change for
| about 6 months now. Right now I am just trying to survive
| and learn the basics of software development.
|
| When I was PM I certainly had the luxury of working with
| invaluable devs I could brainstorm with on ways to optimize
| a feature idea that maintained customer value in the
| shortest time possible. I need to learn how to become that
| invaluable dev I had.
| gugagore wrote:
| 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.)
| jononor wrote:
| Business is not outside the domain of software
| engineering. "building the right thing" is more important
| in engineering than "building the thing correctly". If
| the proposed solution or problem to be solved misses the
| mark, most of the potential value has been lost, and
| excellent execution will not be able to recoup that.
| nitrogen wrote:
| 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.
| gugagore wrote:
| This requirement might never have reached a software
| engineer in many organizations, and perhaps that's what I
| mean. So part of the mastery is ensuring you are around
| to provide solutions when business needs are being
| deliberated. That's fair.
| ZephyrBlu wrote:
| If your only skill is being able to write code, your
| skillset is relatively weak.
|
| We are called Software Engineers, but what we really are
| is people who solve problems with code.
|
| The important part is solving the problem. The fact we do
| it through the medium of code isn't that noteworthy.
|
| If solving the problem requires knowledge from outside
| the domain of programming (Spoiler: it almost always
| does), then you learn what you need to from the relevant
| domain.
| mechEpleb wrote:
| 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.
| gugagore wrote:
| Your use of "spec" here is a weasel word to make your
| point. There are many kinds of specs. The spec here is
| "users need a physical copy", the organization was
| intending to solve it by using the services of another
| business and a bunch of other expensive and complicated
| stuff that I was considering as categorically different
| from software.
| mrmonkeyman wrote:
| It is ridiculous they don't think of this themselves. Not
| in technical detail, but just the general idea. It has
| nothing to do with tech, just thinking. I feel thinking in
| general has been outsourced.
| [deleted]
| banner2018 wrote:
| Precisely the reason why next time you would consider
| debating what's in it for me, prior to blurting out a
| solution.
| Ma8ee wrote:
| I hope you are joking: "I, a paid employee, have a
| wonderful solution to our problem that will save the
| company a lot of money, but I won't tell you if you don't
| pay me even more." I think the answer to that would be
| something like "hmm, if you aren't willing to do your job
| for the salary we already pay you, I don't think there's
| any reason to pay you at all."
| arrosenberg wrote:
| > 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.
|
| Experience flips this equation around. The PM is creating the
| roadmap based on my input and expertise to decide what will
| be the most valuable use of resources. You move from
| construction worker to architect.
| jmchuster wrote:
| As stated by a previous head of product, great senior
| engineers can choose to switch jobs and instantly become a
| great PM.
| aste-risk wrote:
| There are some teams that only work on high impact projects.
| If you feel that your current team is only doing work that's
| not valuable, you need to change teams or at least let your
| manager know to change your project. Ask for projects that
| you think will bring revenue to the company. Revenue = impact
| or increase in productivity of other engineers (this may
| involve writing an internal tool, etc.)
| mkinsella wrote:
| 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.'
| ZephyrBlu wrote:
| 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.
| mixermachine wrote:
| 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.
| [deleted]
| P_I_Staker wrote:
| 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.
| taphangum wrote:
| Fantastic definition.
| bedobi wrote:
| 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.
| kostarelo wrote:
| 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.
| arcticbull wrote:
| That's a tough one. Often the sensibility about what needs
| to be done comes from hours/weeks/month/years hacking away
| at their codebase in their specific setting. Much of that
| has to be rebuilt from scratch in a new place. If you don't
| find that same connection with your work at the new place -
| or are unable to develop the relationships with your peers
| or your manager, you may not end up able to make that
| impact at the new place either.
|
| I tend to encourage folks who come to me about quitting to
| explore opportunities within the team/organization/company
| before leaving so they can leverage all the social capital
| they've built up.
| kostarelo wrote:
| Absolutely, especially in bigger organisations where one
| part may be completely different in terms of how is
| organized and how is operating from another one.
| plutonorm wrote:
| If you are not being heard where you are it's very likely
| the culture is toxic or you are not respected. In either
| case it's time to leave.
| crispyambulance wrote:
| 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
| problem. It's _really_ hard to identify candidates that are
| true masters at what they do (let alone getting them to
| quit their job and join your team).
|
| By the same token, it's also _really_ hard for true masters
| to find a place that understands their value and, more
| importantly, will allow them to do their thing and provide
| career satisfaction. A lot of talented people are locked
| out of jobs because someone thought their career trajectory
| wasn't quite right/impressive.
|
| Training and mentorship, however, are better understood and
| have lower stakes. It makes me think of Bell Labs. I know a
| couple folks who worked there who had very "unimpressive"
| backgrounds, they started as techs but rubbed elbows with
| stellar talent in a place that cultivated discovery and
| collaboration. Over time while there and in other places
| they were able to rise to principal design engineers,
| beyond what many who went to elite universities achieve.
| They credit their formative years in Bell labs with getting
| them started on their career path.
|
| The thing is, Bell Labs didn't have an epically selective
| hiring process, nor was the compensation insanely high.
| They provided an environment that _attracted_ people with
| mastery and those who were passionate about what they do,
| they developed talent within their walls rather than trying
| to merely buy it or find it.
|
| This was for electrical engineers, but the same ideas can
| apply to software engineers.
| arcticbull wrote:
| 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 people
| onboard with your plans.
| conductr wrote:
| 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, or somebody else is really pushing for the
| investment. That's the point where a technical person takes
| over and builds what's asked, or a really great technical
| person may ask a few questions and raise a few points
| nobody else considered and the whole bubble bursts as we
| realize it's not feasible/or we can test it in a certain
| way before investing big time/money into it.
|
| Probably not mastery of SE as OP asked. But mastery as a
| business partner within an organization.
| healsjnr1 wrote:
| That sounds amazing, sadly in a lot of organisations that
| isn't how it pans out.
|
| Either the engagement with technology doesn't happen
| early enough, or when it does, the technology point of
| view isn't given the weight it deserves. The ideas have
| already caught and too many people are invested and have
| 'faith' it will all work out.
|
| The crux of this is that many of those people who carry
| the weight in decision making don't actually carry any
| risk or responsibility for delivery. Given the scale of
| engineering and time to deliver, by the time it comes to
| fruition they've moved on, so they never experience
| accountability for ignoring the advice.
| conductr wrote:
| True. I've witness all of these things as well. I'm not
| implying that organizational decision making is perfect
| if only it had better technical people providing inputs
| by any means.
|
| Again as a finance guy, this is a major skill I have
| attempted to develop for myself/team. When projects spin
| up, I'm typically at forefront and involved in every
| project technical or not (controlling the purse strings).
| Many finance guys are know it all's TBH. They build their
| ROI models, etc. and making dozens of assumptions it's
| then treated as gospel. For some reason, it's valid to
| ask "why is this project underperforming our
| expectations" but it's often taboo to ask "did our
| expectations even make sense". I try to change that where
| it exists too.
|
| All to say, people like me find people at the onset of
| the project to gather inputs. If I know you as well
| versed with track record of valuable insights, I'm more
| likely to reach out early. If I have worked with you at
| this stage and you your input is just one of "we need
| specs/tell us what to build and we can build it" you've
| not added any value to the conversation and I'm likely to
| not include you next time because I know I just need to
| bring you specs once project is approved and that's a
| different conversation for another day.
|
| This is why I say "business partner". Being able to
| understand your company, the politics within, how
| decisions are made, where you can inject value along the
| way. These are all traits of people with fast career
| growth in slower growing firms. You transform from
| Programmer #13 to people knowing and respecting your
| name. This is important in talent reviews, etc.
| disgruntledphd2 wrote:
| 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 normal distribution
| while looking for a way to reduce storage requirements
| for an analytics product).
| robertlagrant wrote:
| If you have a load of smart engineers, sometimes it can
| be a more successful strategy to just build something
| than to pay EY PS250k 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.
| disgruntledphd2 wrote:
| 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.
| PaulHoule wrote:
| The FANG method of software dev is extraordinarily
| expensive, particularly at the G.
| asdffdsa wrote:
| 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.
| conjectures wrote:
| Unfortunately this assumes that the politics of the city
| council is somewhat outcomes focused. If the mayor is
| intent on awarding the contract to her uncle no amount of
| 'soft skills' will help (and attempts to apply them may be
| counter-productive).
|
| It's usually helpful to have an internal locus of control,
| and look for things in oneself (here, soft skills) that can
| be changed. However, sometimes reality just doesn't afford
| opportunities in a given situation. Accepting where that is
| that case means being able to extract oneself from a
| situation rather than wasting time on it.
| ragar90 wrote:
| If you do not know how to build a bridge you should not be
| in charge of taking the decision of howto build it
| mpweiher wrote:
| 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.
| arcticbull wrote:
| That's an unfortunate function of being human. The right
| idea won't always win if it's coming from the wrong
| person.
| Aeolun wrote:
| You can be as nice a person as you want, if you are talking
| with an asshole, you are in for a bad time.
| PaulHoule wrote:
| I worked at one place that was a basket case and finally
| started to push back. The HR person seemed shocked that I was
| concerned with the business value of a project, but i had
| people telling me i wasnt worth what i was being paid -- I
| could show the next assignment had $0 in business value so if
| i spent more than 0 hours on it I'd just be digging myself a
| hole.
| stonecharioteer wrote:
| 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.
| [deleted]
| davewritescode wrote:
| 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.
| intricatedetail wrote:
| Sounds like trauma bonding. I'd leave yesterday unless
| there is a bad market.
| banner2018 wrote:
| Precisely my observation of last couple decades.
| intricatedetail wrote:
| 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 managers egos.
| guytv wrote:
| 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 fail in their
| business.
|
| so you're probably better off take a possible temporary pay
| reduction for a better happiness and higher pay on the long
| run.
| intricatedetail wrote:
| All valid points!
| jkingsbery wrote:
| Most engineers I know in this situation move on to a new
| project before too long.
| mstipetic wrote:
| Can we stop using this word leader? What's wrong with the word
| manager?
| JackMorgan wrote:
| They're totally different words. I used to be an engineering
| manager with direct reports who wasn't really much a leader.
| Today I'm an engineering leader without any direct reports.
|
| Leadership happens from the front and doesn't really have
| anything at all to do with year end reports and making sure
| everyone shows up on time. Management rarely does more than
| HR busywork. The way many engineering mangers work they often
| have skills so outdated as to be effectively non-technical.
|
| Leadership can happen at all levels regardless of title.
| Leaders often are some of the most skilled technicians, able
| to have an outsized impact on both the team and the
| direction.
| mstipetic wrote:
| I think that's an artificial split. Management is not only
| about HR busywork, it should also include all the things
| you've mentioned in the leader category.
|
| Is it an official title? I keep seeing it everywhere now,
| everyone is a "leader." What exactly does it mean? Do you
| proclaim yourself a leader, is there some vote on it?
|
| From my perspective it's completely meaningless and usually
| ego stroking.
| yowlingcat wrote:
| > the best ones can direct a whole team away from large swaths
| of work that is not valuable
|
| Can't overstate how valuable this is. A team which can expose
| its members to this kind of leadership by example and direct
| collaboration will grow and outproduce teams which don't by an
| order of magnitude.
| jl2718 wrote:
| Imagine an evaluation system based on this principle. It would
| be simple cost minus benefit, without regard to technical merit
| or project milestones or other silly process-based evaluation.
| This is the opposite of most companies. Generally promotions
| have to do with the size/cost of an employee's piece of a
| project, not the benefit. Managers would be fighting to reduce
| their team sizes. I don't know how you would back-propagate
| value though.
| m463 wrote:
| 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.
| k3liutZu wrote:
| 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).
| m463 wrote:
| > it gets harder to convince management of future issues
|
| 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...
| hyperpallium2 wrote:
| (just unpacking) Prediction of value, initially and over time,
| requires market analysis.
|
| Given that, predicting which projects will produce that value,
| and which designs will accommodate future additions of value,
| is engineering.
|
| I still like Parnas's _On the Criteria to Be Used in
| Decomposing Systems into Modules_ , where the choice of
| "information hiding" requires predicting what is likely to
| change - and predicting value.
| bribri wrote:
| I agree with this. The best engineers choose the best targets
| dusted wrote:
| One has to be very careful in determining what work amounts to
| "value shipped". It's not uncommon to have a few persons who
| seem to ship all the value, while the rest.. just enable them
| to do so, by doing the required, but invisible stuff, like the
| refactoring required for the new feature to ship, or fixing the
| bugs that makes the customers not leave, or attend those
| meetings that has to be attended by someone. This is somewhat
| related to the 10x engineer story, sure, some are a lot better
| than others, but sometimes it's not entirely undue to their
| situation. Maybe it is a skill too, to be aggressive enough to
| grab the work that looks most valuable and push that through,
| leaving your team to do the rest.
| Cthulhu_ wrote:
| 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".
| narag wrote:
| _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.
| mechEpleb wrote:
| 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.
| narag wrote:
| _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.
| P_I_Staker wrote:
| 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.
| Aeolun wrote:
| Depends on how often I've done something similar before.
| dhsysusbsjsi wrote:
| It's faster for typing my question into stackoverflow!
| shepherdjerred wrote:
| If I'm creating something from scratch or refactoring then
| a keyboard definitely gets in the way. Of course when I'm
| writing something from scratch I usually iterate a few
| times before I have code that I'm satisfied with, so going
| through those iterations requires a lot of moving things
| around.
|
| 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.
| hliyan wrote:
| 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.
| tbrownaw wrote:
| Depending on what I'm working on, just dumping stuff to an
| IDE buffer at 70WPM can be 10% or more of the time
| something takes. Which is enough that typing slower would
| have a noticeable impact.
| davmar wrote:
| I don't know, but I one practice along my journey has had a
| surprising impact upon my skill development. That one thing is: I
| started coding in VIM. For some reason, making that change has
| improved my thinking, and that's been a big part of my growth.
|
| So, maybe you'll find that to be a helpful practice as well. It's
| worth a try.
| bhattisatish wrote:
| I don't want to sound over critical. It's not about the vim.
| Can you generalize it a bit more? Let me take a shot at it(!?)
|
| You introduced a new tool to your workflow. The consequences of
| that was
|
| - Lower productivity initially - You where forced to think
| about how you create/edit your code
|
| So, what made it work for you?
|
| - Thinking about how you structure and edit your code. This
| gave you some clarity around how to think and solve a given
| problem. Longer you practiced this, better you became at it.
|
| - Learning a new tool made you a better at certain things (Say
| how you manipulate large amount of text?). Better you became,
| more confidence you derived out of it. More confidence resulted
| in taking up more harder problems, and the cycle continues.
|
| - You have started thinking about your tools. You spent time
| and energy in learning it. This has broadened how you think
| about software development. This in turn has widened your
| ability to look at the software problems.
|
| I am not sure what I wrote resonates with you or not. But this
| is what I took away from you response "Making that change has
| improved my thinking"
|
| I feel, it's not the choice of the specific tool that made a
| difference, but the result of changing your regular habits that
| VIM bought about in your way of writing code. I am sure, a
| person who changed to emacs or Jetbrains also would have seen
| something change :-)
| davmar wrote:
| Great question and it's not overly critical. I'm afraid I
| can't give you a satisfying answer even though I would like
| to because even I'm not sure why VIM acted as a catalyst for
| me.
|
| What I think it did for me is two things:
|
| - the splits allows me to have multiple files (aka buffers)
| open at ones time and this might decrease the number of times
| I have costly context switches.
|
| - the vi way of manipulating text is faster and more
| efficient in terms of steps needed to complete an edit. I
| believe this reduces the cognitive load of mundane tasks and
| lets my mind stay focused on the actual problem I'm solving.
|
| VI may not help everyone obviously. But I think it opened a
| flood gate for me.
|
| Also the initial lower productivity wasn't really that bad so
| I don't think it had too much of an impact.
| Sevii wrote:
| I'm somewhat doubtful that 'mastering' Software Engineering is
| possible.
|
| You wouldn't ask what it looks like to master the practice of
| medicine today because there are dozens or hundreds of
| specialities and roles all of which contribute to medicine.
|
| Firmware engineering and 'agile' website development are very
| different practices with different assumptions, requirements,
| etc. I wouldn't expect someone to master both web development and
| video encoder development just like I wouldn't expect a doctor to
| be a master pancreatic surgeon and develop vaccines.
|
| On the other hand there is a 'journeyman' level of software
| development and engineering skill that carries over between
| different development areas. It's definitely not algorithmic
| interviews though.
| silicon2401 wrote:
| > You wouldn't ask what it looks like to master the practice of
| medicine today because there are dozens or hundreds of
| specialities and roles all of which contribute to medicine.
|
| This is like saying you can't have a favorite type of rectangle
| because some rectangles are squares. If you're a master of
| neurosurgery, a reasonable person would also consider that to
| be a master of medicine. Just as I would expect a master
| neurosurgeon to not be a master dermatologist but be able to
| master dermatology much faster than I could as a non-medical
| person, I would similarly expect a master C++ developer to
| master Javascript frontend development much faster than a
| junior dev, let alone a non-software person.
| 0xdeadbeefbabe wrote:
| Someone who is good at mental models.
| arensc wrote:
| I agree with what you say
| [deleted]
| AnimalMuppet wrote:
| Handling errors rather than ignoring them.
|
| Knowing that the correct answer to almost every question is "it
| depends".
|
| Knowing how to somewhat-less-inefficiently produce larger-scale
| software that adequately meets the need. (Note that I did not say
| "efficiently", and I did not say "bug-free".) This takes at least
| some skill in dealing with people, not just computers.
| DarkWiiPlayer wrote:
| I'd say the key point is the ability to identify and reason about
| complexity.
|
| Figuring out what the irreducible complexities of a problem are
| and at what tradeoffs these complexities could be addressed in
| different components of an application (including handing them
| off to the user).
|
| A few corollaries of this are:
|
| - Masters will write less code, as they will eliminate most of
| the complexity when there is time for this.
|
| - Masters can more easily put the complexity where they want it,
| having more control over trade-offs between performance,
| usability, flexibility, etc.
|
| - Masters will have an easier time estimating the required work
| needed to implement a project, as experience gives them a good
| intuition for what the irreducible complexity of a problem is.
|
| - Masters will rarely tell you a "right" solution except for
| simple problems. Their answer will depend as much on your
| specific requirements as the problem you're trying to solve[1].
|
| - Masters will often fix problems by simplifying code.
| Refactoring will be a natural part to their coding workflow, not
| a separate "housekeeping" activity.
|
| - Those who hide complexity behind more complexity are not
| masters. Those who always fix problems by adding more code are
| not masters.
|
| [1] It could be argued that "add to numbers and do it fast" is a
| single problem and that's not wrong. Requirements like "speed"
| and "usability" are really just another aspect of the desired
| outcome of a program, but it's rarely thought of as part of the
| problem to be solved, thus I am considering these constrains as
| separate from the "core" of the problem.
| still_grokking wrote:
| https://faculty.washington.edu/ajko/papers/Li2019WhatDisting...
| rramadass wrote:
| 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.
| EliRivers wrote:
| Amongst other signs, they make it look effortless by identifing
| problems long before they become problems and taking small steps
| now to make a better future in a few months time.
|
| I don't see them engaged in "heroic" coding marathons to
| desperately get something fixed or delivered; they already fixed
| it weeks or months ago.
| snarkypixel wrote:
| Ironically, it's often when there's no mastery that you realize
| what mastery is. (I.e. when things just work, are shipped on time
| and are easy to maintain, there's not much fanfare about it)
| xyproto wrote:
| IMO:
|
| The ability to judge risk in terms of time and money.
|
| The ability to judge the amount of security that is needed (a
| productive level that is still safe).
|
| To think long-term, in terms of avoiding complexity buildup over
| time, and in terms of avoiding vendor lock-in.
|
| To help others get up to speed.
|
| To stay productive over time.
|
| To stay open to learn something new.
| [deleted]
| MathematicalArt wrote:
| _INTRO_
|
| To 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.
| chx wrote:
| I have already made the mistake you are about to make.
| GistNoesis wrote:
| I think of tool makers.
|
| Software engineering, gives you some degrees of freedom,
| therefore it's kind of an art form. Therefore mastery is about
| intent and the ability to realize it.
|
| In this canvas, you can ask yourself, is the bearer wielding the
| tool or is it the other way around.
|
| For me a proficient tool user is no master until he makes his
| tools his own. He can become one either by creating them, or by
| understanding them deeply enough that he could recreate them.
|
| There are then various levels of mastery and mastery over various
| sizes of domain. Levels are more about the capacity of imagining
| new tools, and having new visions in order to advance your field
| in some interesting way. Growing domain size is about trying to
| have bigger and bigger tools while still retaining control over
| them.
| knadh wrote:
| Mastery is difficult to quantify, especially in terms of code or
| engineering cleverness. I think, what comes close, is the ability
| to get way more tradeoffs right than wrong, to hit an optimal
| balance. Tradeoffs in decision making when it comes to picking
| technologies or languages, or a certain design pattern, or an
| architecture, or UI/UX or whatever, when building systems. Small
| tradeoffs that may not look like much immediately, but pay off in
| the long term. Sacrificing a seemingly good feature now to avoid
| the pain of technical debt in the future.
|
| Many of these traits are fundamental, universal, and even
| philosophical, than is general perceived, and transcend
| technologies and stacks, and to a large extent, time.
|
| And yet, I think, the above traits can be described as good, and
| not really mastery in its truest sense, like in other disciplines
| like music or painting. Software engineering is way too diverse,
| fragmented, chaotic, and ever changing.
| Daub wrote:
| A simple requisite of mastery in any domain is age. Not to say
| that young people can't be brilliant and impactfull at their
| craft. But such qualities fall more rightfully described as
| having flair. The difference between mastery and flair is that
| the former is more reliable and stable.
|
| As an art teacher, I have seen many young artists go on to have
| great careers shortly after leaving school... but most of them
| burn out or fail in one way or another. Conversely... their aged
| teachers have acquired character, depth and stability but have in
| the process lost their wildfire.
| LordHumungous wrote:
| Ability to design and implement a large scale system from the
| ground up.
| brabel wrote:
| Lots of people here seem to think they know what mastery looks
| like, but to tell whether someone is a master in something takes
| another master. And I doubt most of the people who think they are
| one, actually are.
|
| I will try to avoid doing that myself, specially I will avoid
| implying I am one, but I think it's possible to come up with a
| few criteria to help you "judge" the level of mastery one has in
| software engineering:
|
| * can create a project from scratch without pondering forever
| about each and every choice, while picking reasonable choices
| that, together, approach optimality given the circumstances
| (notice that this depends mostly on the team/company involved so
| there's not one right universal answer).
|
| * can break up the work in manageable pieces so that progress can
| be made (regardless of how many people actually work on the
| project) and measured easily. This is really hard and can only be
| done properly by a practitioner (meaning, no, your PM can't do
| that for you).
|
| * can establish a good base design that facilitates achievement
| of the project's objectives (e.g. if performance-focused, then
| architecture might differ significantly from a more
| maintainability-focused one).
|
| * knows to apply the right amount of testing/automation (too much
| or too little can be damaging).
|
| * can focus on the task at hand, avoiding unnecessary work (many
| great technical developers fail to do this due to their
| preference for harder challenges that may not be the right ones
| to address).
|
| * can communicate well (because knowing it all but not being able
| to pass the knowledge on or convince others will cause most of
| your knowledge to become inaccessible).
|
| Notice that to be able to effectively rate a person or team
| against each criterion is itself something subjective sometimes,
| so you won't get a clear-cut answer no matter how you look at
| it... but I am sure that there are ways to use metrics for each
| one, though we all know the problem with metrics (people will
| game it), so yeah, it's difficult to figure this out. Just make
| sure you don't fall into the trap of judging people solely on
| subjective grounds though as our natural biases are quite
| crippling (see psychological studies about human bias) and will
| cause you to misjudge others, sometimes disastrously.
| HellDunkel wrote:
| Nintendo, Doom, Unreal, Maya (not Autodesk), Nuke, VRay...
| beautiful products altogether. Its almost always teams of people
| but leads are key.
| lincpa wrote:
| The Grand Unified Programming Theory: The Pure Function Pipeline
| Data Flow with Warehouse/Workshop Model
|
| 10 Principles of system design: Take Warehouse/Workshop Model as
| an example
|
| https://github.com/linpengcheng/PurefunctionPipelineDataflow
| ojciecczas wrote:
| Among other things a master splits the I/O code and core logic
| code.
| GuB-42 wrote:
| Nothing specific to software engineering.
|
| But I'd say a master is simply someone you have a lot to learn
| from.
|
| I'd say you have mastered the discipline when even though you
| know the limits of your abilities and you are eager to learn, it
| becomes difficult to find someone to teach you something new.
| trestenhortz wrote:
| It's fiction. No one is a master. There's always stuff to learn.
|
| Competence is a better term. What it looks like is being able to
| make things happen quickly with minimal errors or problems.
|
| Unless you're talking about the most extreme cases ..... Fabrice
| Bellard and John Carmack .... genius developers who are true
| masters. There are few of these.
| keyle wrote:
| Excellent question, but how does one measure the length of a
| string constantly being extended on moving sands?
| breck wrote:
| Pay attention to who was the lead dev on the code you are using.
| When you see that you are using 2+ (sometimes 5+, rarely 10+)
| projects from the same person, then you've found a master. Start
| looking closely at what they are doing, what they are reading,
| what they are saying on their blog, twitter, etc.
|
| I think of Linus, Lars, Anders, TJ, Rich, etc
| agumonkey wrote:
| I fail to decrypt who TJ can be
| SOLAR_FIELDS wrote:
| 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 libraries he
| has written and how good he as at writing them:
| https://medium.com/@kelas/how-is-tj-holowaychuk-so-
| insanely-...
| agumonkey wrote:
| This might explain the 'we repurposed npm to manage go
| deployment' articles I saw recently ..
| steve_adams_86 wrote:
| I don't hear about his work often anymore, but I always
| appreciated his insights and how humble he was. Definitely
| seemed like the kind of person I'd like to work with and
| learn from. Though I suppose I did indirectly - I dug
| through his libraries for years out of curiosity and
| necessity.
| xdavidliu wrote:
| Can you add the last names? Some these are difficult to tell
| who you are referring to.
| rukugu wrote:
| Linus Torvalds, Lars Bak, Anders Heijlsberg, TJ, Rich Hickey
| optymizer wrote:
| Linus TechTips, Lars Ulrich, Anders Holm, TJ Maxx, Rich Nixon
| champagnepapi wrote:
| LOL
| INTPenis wrote:
| In 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, .net and golang to write the components.
|
| This impresses me a lot how our lead can come up with such a
| design and make it work from paper to practice.
| EliRivers wrote:
| Just so. A lot of the problems have already been solved before
| anyone starts typing code.
|
| It is SO common in this industry for people to literally not
| know what some software is meant to do, and just start typing
| code anyway. There's an entire software philosophy, "agile",
| based around that. If it IS known in advance what the software
| is meant to do, the quality of software that can be created is
| just astounding.
| pbourke wrote:
| 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.
| selimthegrim wrote:
| Jeff Koons likes to think he is
| INTPenis wrote:
| I see what you mean but it's more nuanced than that in my
| case.
|
| It's not like he turned 50 and suddenly stopped coding. I'm
| talking about a real nerd, a person who codes even on their
| free time.
|
| And he still writes code in other projects, he's a
| consultant, but in our project he's not touching any code,
| only advising. And he's 50+ now so he has 15 more years until
| retirement.
|
| Of course I've seen people here work beyond retirement
| because our field is so easy on the body.
| fancythat wrote:
| 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, so
| he helped me get everything set up for local iPhone development
| here, which is a lot more tortuous than you would expect from an
| Apple product. As usual, my off the cuff estimate of "Two days!"
| was optimistic, but I did get it done in four, and the game is
| definitely more pleasant at 8x the frame rate.
|
| And I had fun doing it."
| uhtred wrote:
| 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 it done in 4
| days.
| andai wrote:
| Two months of weekdays is about 40 days, so they would have
| be 80 hour days. (Although we also forgot to multiply by the
| number of people on the team...)
| mvanga wrote:
| https://bellard.org/
|
| Clean, well-documented projects showcasing demos that end up
| having huge impact. Some of these projects single-handedly
| spawned entire tech ecosystems. (see FFMPEG, QEMU, JSLinux)
| flixic wrote:
| Was about to comment with the same URL.
|
| It's one "direction" of mastery. Software invention, at grand
| master level.
| raghav_nautiyal wrote:
| Who is John Galt?
| dumbfoundded wrote:
| IMO it's about understanding the solution curve in the problem
| space. Every problem type has a range of possible solutions. Most
| of these solutions are wrong and a few are correct with different
| tradeoffs. When you can't do better without making tradeoffs,
| you're on the curve.
|
| Novice engineers will struggle to get something done.
| Intermediate engineers can get things done but fail to see the
| tradeoffs. Expert engineers can identify possible solutions with
| different approaches.
| throwii wrote:
| How do you learn that solution curve and their tradeoffs? Swap
| jobs and hope you see them all in your lifetime? Read articles
| and hope you pick everything up correctly?
| 0xdeadbeefbabe wrote:
| Seems almost like you are talking about static vs. dynamic
| analysis of programs.
| rramadass wrote:
| Recognition Primed Decision Model -
| https://en.wikipedia.org/wiki/Recognition_primed_decision
|
| Naturalistic Decision Making -
| https://en.wikipedia.org/wiki/Naturalistic_decision-making
| dylkil wrote:
| raw experience
| morphicpro wrote:
| Having a good grasp on time vs space complexity helps.
| mandeepj wrote:
| space is cheaper
| dumbfoundded wrote:
| I'd recommend:
|
| - Working with experts
|
| - Writing and deleting lots of code
|
| - Participating in code reviews
|
| - Reading even more code from others
|
| - Watch & read technical presentations
|
| You can never truly be perfect, you can only approach it.
| Understanding your limitations is just as important as
| understanding your capabilities. Depth vs breadth is hard and
| you only have so much life to go so deep into so many
| domains.
| cbetti wrote:
| Prototyping alternative solutions is a cheap way to help
| uncover trade-offs, and you can do this independently.
|
| Attending retrospectives after things go wrong is a good way
| for experts to introduce their thought processes to less
| experienced engineers.
|
| Asking "why?" when senior engineers deliver feedback during
| design review can help you learn that a trade-off existed
| when you did not see it.
| hinkley wrote:
| I once was trying to design a validation framework. I
| thought it should work this way. The other lead thought it
| should work that way. So I proposed we write some sample
| code for these APIs and show it to the team. TDD with
| pseudocode before any of us knew what TDD was.
|
| Only, I didn't like having two to chose from. Something
| told me three would be better. So we paired, I wrote mine,
| then hers, then just made another one up on the spot. Once
| we agreed they were complete and implementable, I shopped
| them to the team.
|
| About 2/3rds preferred the made up one. Including me. So
| that's what I implemented.
| brazzy wrote:
| Great story! Not a huge surprise when you think about it
| - you made up the the third design just after thinking
| through the other two in detail.
| bird_monster wrote:
| Pre implementation
|
| - Identify and document possible solutions. Think hard about
| why each solution is good and each decision is bad.
|
| - Within each solution, attempt to find common patterns in
| that problemspace (when working with Sharded databases, this
| approach brings these results, etc)
|
| - Try to match your personal and organization requirements
| against the various patterns you find and the pros/cons you
| defined previously
|
| During implementation
|
| - Keep a running list of things that seem weird, or things
| that seem great, or things that turned out to be untrue
|
| - Don't stop implementing, but for each thing you found that
| wasn't great in step 1, try to find a better way to approach
| that thing (while moving forward)
|
| Post implementation
|
| - Compile all the notes you made in pre/during into a
| manageable list of goods/bads.
|
| - Use this to drive A.) iterations of your solution, and B.)
| future solutions
|
| If you do this enough times, you'll have a pretty decent list
| of your experiences in a space, and you'll start to notice
| patterns as you try different things and become exposed to
| problems, their solutions and their tradeoffs. Eventually you
| won't even have to look at your previous notes very often, as
| you'll have built up a pretty decent amount of experience in
| various problemspaces such that you can predict what goes
| well/doesn't go well.
|
| Also worth noting, this type of behavior doesn't really have
| to be applied to software, but will also gain you big points
| with future employers when interviewing. You'd be surprised
| to find how many candidates never stopped to reflect on the
| work they'd done, why it was sub-optimal, or how it could be
| corrected moving forward. Response like "We did it ____ way
| because that's how we always did it." Which, from a progress
| standpoint, is basically a none-answer.
|
| Note: this is obviously just my opinion, and I'm no expert in
| "Becoming a Master of Stuff", but these are the methods that
| I have used and seen my peers use (in one form or another)
| over quite a long time. Sometimes not as obvious (doing these
| things in your head vs. writing them down), but the shape is
| always pretty similar. Ultimately I think being reflective is
| one of the best skills a person can possess (with respect to
| employment and I guess also relationships). Acting without
| thinking is reckless, I think.
| aste-risk wrote:
| > being reflective is one of the best skills a person can
| possess
|
| As they say, pain + reflection = progress. If you don't
| wanna reflect, good luck enjoying that pain without
| progress.
| jjn2009 wrote:
| Sticking around long enough to see a big mistake bite you is
| sometimes better for your growth than swapping jobs.
| mandeepj wrote:
| Definitely this. Nothing like learning from watching your
| solution hitting roadblocks (performance, extensibility
| etc) and reassessing your earlier approaches and again
| coming with a solution to address the newer challenges
| hinkley wrote:
| You can also dig into the problems that existed when you
| got to the project, and try to work out how they came to
| be. Project forensics is a skill set unto itself. And
| listen to and help people on other projects at your
| company. You can see how their story arc goes and where it
| surprises you.
|
| An intelligent man learns from his own mistakes. A wise man
| learns from the mistakes of others.
| 1penny42cents wrote:
| OP is giving a problem solving framework, it's not tied to
| specific solutions or tradeoffs. It's more of a method for
| thinking through a solution.
|
| In more detail, the steps go like this.
|
| Find as many solutions to a given problem as you can. Bad
| engineers run with the first solution that comes to mind,
| letting confirmation bias drive them.
|
| Evaluate each solution for its costs and benefits. Imagine
| two steps in the future when the solution is implemented.
| What pains are there?
|
| Search for creative new solutions that create win-win
| scenarios. That's riding the solution curve.
|
| Given all viable scenarios, compare the costs and benefits
| against the quality measures for your specific context. Some
| projects value speed over precision. Some projects value
| performance over extensibility. Some solutions are easier to
| change later than others. This is choosing a specific point
| on the solution curve that best fits your context.
|
| You can apply that method of problem solving to any problem,
| large or small. You don't need a ton of experience to
| practice it.
| aisofteng wrote:
| This comment made me realize what my mentor did years ago.
| He would have the entire team list all possible solutions
| to a problem, including the obviously bad ones, then have
| us whittle down the list based on pros and cons of each
| until we reached consensus on what to do. It was a teaching
| exercise and I didn't realize it.
|
| I've repeated it that exercise with junior engineers to
| great effect. Some catch on over time and start intuitively
| considering the trade offs of a few reasonable solutions to
| a problem; some don't.
|
| I never reflected on what he was doing there; thanks.
| jaggederest wrote:
| To add to that, some of the smartest "good" ideas come
| from "bad" ideas that people rejected out of hand,
| sometimes from unusual sources. It pays to do
| brainstorming thoroughly.
|
| The best software engineers know when to solve a problem
| without using any code at all, like the classic "just do
| it manually" for a complicated task that is worth more
| than $x per task.
| kube-system wrote:
| Additionally, expert engineers can better define the problem
| space to begin with. Some engineers can get things done and
| evaluate tradeoffs well, but end up solving the wrong problem.
|
| Expert engineers have the ability to think about a problem in a
| broader context than the engineering problem at hand.
| bilkoo wrote:
| "Talent hits a target no one else can hit. Genius hits a
| target no one else can see." - Arthur Schopenhauer
| hinkley wrote:
| Don't worry about people stealing your ideas. If your ideas
| are any good, you'll have to ram them down people's
| throats.
|
| - Howard Aiken
| koolba wrote:
| That's a beautiful quote.
| bokohut wrote:
| "to think about a problem in a broader context" << this
| j0d436 wrote:
| You're right, except you sell your own answer short when you
| say "curve". In practice, the set of trade-offs has a much
| higher dimensionality, and solutions are much less often
| strictly "wrong" as they are "less optimal" or "out of scope".
|
| Now, you might be thinking " _that 's not true, if I implement
| a function to add two numbers, and it returns 1+1=3, that's
| wrong. So that's a clearly wrong solution._" But I argue: is it
| wrong? What's your context? What are your acceptable trade-
| offs? In many real-world applications, precise correctness
| isn't always critical. Sometimes, sacrificing accuracy might be
| acceptable, and may save on cost and/or complexity. Other
| times, that's not acceptable. But it's worth considering even
| these types of non-obvious trade-offs, not just the obvious
| ones. That's what an expert engineer does: ask the right
| questions and identify the right trade-offs, and they've become
| efficient in that process from experience.
|
| An expert sees a problem space as a wide range of trade-off
| dimensions, including: * computational
| performance * memory performance * implementation
| complexity * maintenance complexity (understandability)
| * accuracy * reusability * design time *
| reliability * debuggability * bug-proneness *
| scalability * etc.
| tr1ll10nb1ll wrote:
| George Hotz lol
| ipiz0618 wrote:
| IMO, it's knowing how to balance code quality and handle errors
| within time constraints and other restrictions. Any simple
| application has the potential to be very complex when one wants
| to handle every possible scenario. Knowing where to draw the
| line(s) would be what I consider mastery.
| phendrenad2 wrote:
| Mastery of software engineering means, given any task, you can do
| it, at any point along the fast/correct/cheap triangle gradient.
| In a corporate environment, you might lean toward fast and
| correct. In an open-source context you may lean toward correct
| and cheap. At a pre-funding startup, building an MVP, you may go
| with fast and cheap.
| friend-monoid wrote:
| I think a better wording is "you can learn how to do it";
| treading new waters is a daily task for software engineers.
| collyw wrote:
| Something that makes sense to the next developer without too much
| effort (assuming that it works).
| bob1029 wrote:
| For me, mastery is all about managing complexity. In my
| experience, most of the complexity in a software system emerges
| from excessive shared state between components and poor modeling
| of the domain.
|
| If you can break your problem up into smaller, independent
| pieces, you can pretty easily manage complexity throughout.
|
| By having a good domain model (which to me means context-agnostic
| and represented approximately in 3NF/BCNF), you automatically
| clear up most of the nasty interfacing between components. Also,
| having a domain model in a normalized form enables much easier
| querying for any required dimension of fact (i.e. SQL/LINQ/et.
| al.). The methods will almost automatically follow from a good
| domain model.
|
| Being able to develop good models of the domain and manage
| incremental complexity are the hallmarks of a master software
| engineer. You should note that neither of these fundamental
| skills requires the use of a computer.
| codingdave wrote:
| I 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.
| unsatchmo wrote:
| Length of time doing something doesn't imply mastery. It can
| contribute to mastery, but only if you're always pushing your
| skill to the next level I think.
|
| For example: I know people who have been skateboarding for
| decades and are just barely OK at it. How you practice matters.
| karlmcguire wrote:
| I think most "master" software engineers are a bit more
| idealistic than that... Not saying I am a master but I
| occasionally write something and consider it genuinely
| beautiful.
| jacobsenscott wrote:
| Mastery is when the code you wrote 6 months ago, or a year ago,
| or five years ago is still running, and not causing problems.
| Mastery is when the code you write brings long term benefits,
| and not future problems.
|
| I've both seen and written code like that, so it does exist.
| Like anyone one else I've also written code that causes future
| problems. I believe I'm at a point in my career (25 years in)
| where I now write more of the former than the latter.
| tsumnia wrote:
| > I don't think there is mastery in this work.
|
| I take it one step further, I don't believe mastery exists, or
| rather we don't have a consistency on what mastery 'is'.
|
| I prefer the saying something along the lines of "expertise*
| just means you get in more trouble when you do it wrong"
|
| * Expertise is replaced with 'black belt' for martial art
| expertise
| sojournerc wrote:
| I think it's more like that quote from a supreme court
| decision about porn, it's very hard to define but you know it
| when you see it.
|
| I play violin, and know and admire many masters. What makes
| them so good is fun to study and pursue because they are
| worth emulation.
|
| But it's not some secret or hack. It's a million small things
| and a lot of feel.
| poulsbohemian wrote:
| codingdave, I think you really hit on exactly the right point,
| and in doing so have also spoken to my mind exactly where we've
| gone off the rails as an industry in our hiring practice.
|
| When we interview people, we do so in such a way that we
| believe someone is capable of showing mastery of the field,
| where those who have been in the field a long time and agree
| with your philosophy here know that about all we can can hope
| to achieve is humility.
|
| It also feels like this fundamental to why this field has not
| been able to mature to a point of being a profession in the
| same form as other fields - because while we can teach a lawyer
| the law and we can teach a doctor a particular way to perform a
| technique, software is all just a bit wet and sticky.
| P_I_Staker wrote:
| 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.
| Lammy wrote:
| > I don't think there is mastery in this work.
|
| I think there is mastery, but only in knowing that there is no
| mastery.
|
| "I seem, then, in just this little thing to be wiser than this
| man at any rate, that what I do not know I do not think I know
| either." [Apology of Socrates, Henry Cary literal translation]
| dumbfoundded wrote:
| That's the right mindset for an individual but not particularly
| helpful for an answer. Constant improvement is part of mastery
| but not a great yard stick.
|
| I also have trouble believing you've been coding for so long
| and can't take pride in any of the code you've previously
| written.
| ChrisMarshallNY wrote:
| I'm proud of my very first shipped engineering project:
| https://littlegreenviper.com/TF30194/TF30194-Manual-1987.pdf
| (Downloads a PDF).
|
| I think I do what I do pretty well. The folks I work with
| seem to like it.
| bcrosby95 wrote:
| Is that code from 6 months ago crap or just different than your
| current preference? I see a fair number of people churning
| between solutions that are more different than actually better.
| BatteryMountain wrote:
| I also have this battle. It feels like each time I take another
| step up the mountain, the mountain itself grows.
|
| Doesn't matter how much time/effort I expend, there is just no
| way to keep up to date with every moving piece in our industry
| (from hardware, to firmware, to software, to laws, to
| programming languages, to cryptography/security, to web
| standards, to multimedia standards/codecs, to physics etc). It
| seems like every single action that we take comes with trade-
| offs and that we can never make an ultimate good choice - that
| choice is only valid for a short time before it's trade-off
| gets triggered.
|
| A carpenter has a set of tools. He has a set of materials. He
| has a set of blueprints/techniques. He can consistently build
| table with x qualities. When he is done with the table, it is
| done. He doesn't have to spend all of his time relearning how
| to build tables over and over, and for old tables to quickly
| self-destruct if he stops baby-sitting them. Or for some 12
| year old carpenter in Russia to cause his table's wood to rot.
|
| Every year that passes by, humans accumulate more and more
| knowledge. It would be impossible for a few individuals to know
| everything as their time in this life is limited. Thus we get
| forced to specialize, else we can get pulled into the general
| knowledge stream which can be overwhelming.
| LeicaLatte wrote:
| Clearing a FANG interview. It does take months to prepare for
| even if you are a master.
| johndoe42377 wrote:
| In the field of programming languages design and implementation
| look no further than Erlang, MIT Scheme (a true gem), GHC, Scala
| and Go.
|
| Those are creations of exceptional masters.
|
| For smaller projects take a look at nginx, Tokyo cabinet (a DB),
| redis, and, perhaps, python's requests and Clojure (one man's
| effort to unify obvious things).
|
| Again, these are masterpieces, not just merely good things.
| ExcavateGrandMa wrote:
| As a master... I sit in front my computer and write program(s)
| from all kind (with and without refs)...
|
| using either libs or not...
|
| This is not what I think... This is what it is.
|
| Gl...
| computerdork wrote:
| This is of course a matter of opinion, but for me, seems like
| there are three sides to this:
|
| 1) Knowledge of the core theories of computers: core ideas of
| computer architecture, good understanding of computational
| complexity (how long a program will take to run), networking...
|
| 2) Knowledge of software technologies: Python, Javascript, Java,
| C, Docker, Functional Programming, Object-Oriented Programming...
|
| 3) Knowledge of software engineering concepts: Software
| architecture, software process (agile, requirements gathering,
| testing), software complexity (and how to minimize it through
| good architecture and processes), general engineering principles
| (redundancy, fault-tolerance, solving problems early in the dev
| process...).
|
| To me at least, the one that is neglected the most is the third
| one, "software-engineering concepts." Being able to think about
| systems at a high-level and well at the detail-level is one the
| most useful skills for an engineer.
| [deleted]
| gitgud wrote:
| "Software" is the implementation of logic. "Engineering" is
| solving problems with science, within a set of constraints.
|
| Therefore software engineering, is solving problems with logic,
| within a set of constraints.
|
| Where constraints can be; business requirements, hardware
| limitations, development time limitations, performance limits,
| solution simplicity, release frequency... Etc
|
| Mastery of software engineering is efficiently solving problems,
| and optimising for the constraints that matter...
| arensc wrote:
| Hey So I view Software Engineering as a multidimensional
| optimization surface where you have to optimize for a goal by
| choosing an axis and playing with those axis until you get a
| desired result.
|
| Mastering the language but understanding why the language was
| developed what problems it looked to address.
|
| Reducing the cognitive load of the design using the language.
|
| Understanding the fundamentals of the types of applications you
| will be building. SCRUD Architecture Apps Streaming Architecture
| Apps and Games which are usually a combination of both.
|
| Software Systems from first principles are read and write
| systems. How do you represent that as a program and reduce the
| complexity?
|
| How you view software engineering ? and explain it to others what
| is the method of representation you use to encode software as
| plumbing? is it text based? time flow graph node based? stack
| based ? binary based ?
|
| Software engineering as a team sport, how do you get a bunch of
| developers to reduce the cognitive load manage the relationships
| and data in the code and how do you measure that like a science.
|
| I am also sure there is a lot of valid advice here as well. This
| is how. I see it from a mathematical / science perspective that
| pushes pragmatic narrative.
| natenthe wrote:
| Is this a parody?
| ununoctium87 wrote:
| Maybe someone trying out a badly trained GPT-3 generator
| arensc wrote:
| I realized something while explaining this, it might be
| intractable to explain other than to just use basic blanket
| statements lol
| kubanczyk wrote:
| TIL: SCRUD == Search + CRUD
| MarkMc wrote:
| Mastery in any field involves 4 components: Accumulation of
| knowledge, conceptual understanding, judgement and skill
| tsjq wrote:
| Perfect estimates, deep insights, and anticipating challenges
| mytailorisrich wrote:
| I would say that even just _aiming_ at perfect estimates is a
| sign that mastery has not been achieved yet.
|
| Wisdom is to acknowledge uncertainty and that estimates are
| uncertain in nature because the information available at the
| time is always incomplete.
| ironmagma wrote:
| Yes, but there are also situations that demand certainty and
| accuracy in estimates. One must appease them by looking as
| though you are trying.
| orisho wrote:
| That's only if the challenge is completely new. Sure, if
| you're researching something novel in an area you've not
| worked on, the information you have is likely very far from
| complete. But if you're writing a backend server for a new
| POC for the umpteenth time in your career, you're likely to
| be able to do it fast, well, and be able to estimate how long
| it's gonna take. The reason being that the unknowns are slim
| to none.
| jonathanstrange wrote:
| Masterful code has some kind of straightforward simplicity. Every
| function does one thing and does exactly what it is supposed to
| do. Everything is very predictable and boring. You can see from
| the code how clearly the programmer was thinking and how well the
| program structure was planned.
| milchek wrote:
| Is it possible? Maybe if you say a specific language, yes, but
| even then, there are new versions or iterations where whole new
| features are introduced.
|
| Mastery in software engineering needs to be defined very
| specifically.
|
| An example, I used to build Flash microsites, campaigns and games
| for an ad agency. I had a very good grasp of the tech, built
| projects for large clients etc. If you looked at me at that point
| in time you could say I had mastery, but now Flash is gone, and I
| didn't switch over to React and other web based tech soon enough
| so my "skill" is lesser than someone who purely started in that
| domain.
| Ayesh wrote:
| - Sqlite
|
| - Symfony framework
| kcorey wrote:
| Software Engineering doesn't exist in isolation.
|
| You can't master Software Engineering without mastering
| interfacing with the rest of the organisation.
|
| I don't care how intellectually pure your implementation is or
| how fast you deliver things. If it can't easily connect to, use
| and get used by the rest of the business, it's a folly.
|
| A master of software engineering delivers what the business needs
| in the minimum time possible.
|
| Some businesses care about maintenance. Some don't.
|
| Some care about UI/UX, others with a trapped audience don't.
|
| Some care about efficiency and optimisation, others don't.
|
| You can't be a "master" until you have a sense of what your
| business is interested in. Not what it _CLAIMS_ to be interested
| in, but really cares about.
|
| It's been different in every company I've ever worked for.
|
| Good luck.
| yagizdegirmenci wrote:
| > Some businesses care about maintenance. Some don't.
|
| Yes, that's right. It's also a choice. You don't have to work
| for a company who does not care about maintenance.
|
| At least I wouldn't, people should have own their standards.
|
| With that codebase you are going to spend your 1/3 of your
| days. It really matters.
| itisit wrote:
| https://www.bti360.com/what-ive-learned-in-45-years-in-the-s...
| jasonpeacock wrote:
| Consistently and reliably delivering good software solutions.
|
| Just like a master woodworker would consistently and reliably
| deliver good furniture.
|
| Or a master author would consistently and reliably deliver good
| books.
|
| The key points are:
|
| * Consistent - It wasn't just a fluke or luck, you know what
| you're doing and can repeat it.
|
| * Reliable - You know how much effort it will take and can
| deliver it.
|
| * Good - It's not crap, people want it.
| asddubs wrote:
| seems like there's an intersection with mastery of product
| design there
| kubanczyk wrote:
| What if a woodworker is an employee of a big org? (IKEA?) None
| of your points regard interacting with people downwards _and_
| upwards.
| [deleted]
| simplecto wrote:
| Actually coding something is the last resort.
| jugjug wrote:
| I think of Rich Hickey [1]: helping others to understand the code
| faster by identifying and removing most of the accidental
| complexity.
|
| [1] https://www.infoq.com/presentations/Simple-Made-Easy/
| abdabab wrote:
| This reminds me of a talk of Linus Torvalds. From this
| perspective, mastery can be seen as an acquired taste that came
| after doing a large volume of work.
| rramadass wrote:
| Can you please link the talk?
| abdabab wrote:
| 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
| rramadass wrote:
| Ah; i had seen the TED talk earlier though i had not
| looked at the code example in detail.
|
| Thanks for the links.
| blackrock wrote:
| Two words: Functional Programming
| millstone wrote:
| Functional programming is taught in schools, so engineers
| straight out of college know it. I was one of them!
| lackbeard wrote:
| Example masters: John Carmack, Jeff Dean, Bram Cohen. What do
| they do? I think they're all extremely effective at getting
| things done. So be smart, hard working, and laser focused on
| shipping.
|
| A long time ago I saw a good talk by Jonathan Blow wherein he
| made a point that really resonated with me. The point was that to
| get good at programming you need the experience of shipping a lot
| of programs and thus you should optimize your career around
| shipping as many good programs as you can. Contrast this with the
| common advice of being an expert in databases, or distributed
| systems, or OOP, or testing, or something like that...
|
| Edit: found the talk: https://www.youtube.com/watch?v=JjDsP5n2kSM
| collyw wrote:
| To play devils advocate. Perl 6 is an example of where not
| shipping was a major contributor to the decline of the
| language. Shame, as it looks interesting.
| lizmat wrote:
| If you think it looks interesting, you should have a look at
| Raku (https://raku.org using the #rakulang tag on social
| media). Looks familiar? It should be, as it is the new name
| of Perl 6. It now also comes with an IDE
| (https://commaide.com) if you're so inclined :-)
| collyw wrote:
| Is that just a rebrand? Wasn't Raku one of the
| implementations?
| revskill wrote:
| Problem solving skills. It doesn't matter if your tool is the
| best, it only matters which tool is suitable for the job.
|
| So the master to me is the one who knows which tools for which
| job !
| known wrote:
| https://en.wikipedia.org/wiki/Code_refactoring should do;
| kmclean wrote:
| I like Mozilla's descriptions of increasingly senior roles.
| https://twitter.com/Gankra_/status/1046438955439271936/photo...
| rusk wrote:
| Highly competent in at least 3 languages; general understanding
| of 5 others; good written communication and presentation skills;
| able to create gui; understanding of distributed systems and
| networking; unix command line; can at least rebase in git
| mlthoughts2018 wrote:
| Why on earth would _number of languages_ have anything to do
| with it. That doesn't make sense. Parochial number of languages
| doesn't capture the idea of understanding multiple paradigms,
| low level / high level, type system considerations.
|
| A person might have zero experience except _Node.js_ yet still
| show high mastery of functional programming, mixed OOP, design
| patterns, compilers, etc.
|
| Setting any threshold on languages just sets up a meaningless
| metric.
| rusk wrote:
| It's just a simple and objective yet general measure of
| mastery
|
| If you have these skills there is a very high likelihood that
| you can do most other things that are thrown at you
|
| Most of the other answers have all these high level wishy
| washy specifications, I thought I'd take a more brass tacks
| approach.
| CyberDildonics wrote:
| It is mostly beginners and students that think learning
| programming languages is difficult or is a big part of the
| difficulty of writing software.
| rusk wrote:
| Well I'm neither of these so ...
|
| I suppose this list could be called necessary but not
| sufficient. The question is what does a master "look
| like". If you can only work with one or two languages you
| are by no means a master.
| max_ wrote:
| My definition of a "Master" is someone that can churn out
| software that is both;
|
| - High performance (in terms of efficiency in using computational
| resources)
|
| - Reliable i.e does exactly what we want and doesn't crash. This
| also includes clear documentation.
|
| I think to reach there, some of the things one may want do are;
|
| a) Learn TLA+
|
| b) Study hardware (processors, memory)
|
| c) Study software, protocols like tcp/ip
|
| d) Build experiments & ship
| indymike wrote:
| They build better software. They are both strong contributors
| individually, and strong team members. Better is relative to
| whatever the purpose of that software is. If it needs to be fast,
| it is. If it needs to be secure, it is. If it needs to be made
| quickly, it is.
| throwaway889900 wrote:
| Fabrice Bellard, the mind behind FFMpeg and QEMU.
| permille42 wrote:
| He is one of 3 people that came to mind immediately reading
| this post. One of his latest creations, QuickJS, is quite
| remarkable.
|
| The other two I thought of are Peter Norton and Linus Torvalds.
|
| Fabrice, despite his tremendous contributions to the field,
| doesn't reach for acclaim and just seems to go his own way.
|
| Peter Norton was a genius in his field. His book on Assembly
| Language was one of my favorites as a youth. Norton tools were
| impressive for their time.
|
| Linus, as the namesake for Linux also made a huge impact on the
| field... and comes off as somewhat of an uncontrolled lunatic.
|
| I don't though think that these three people are the highest
| level masters in the field. I think they are just the ones who
| have chosen to do things that have high impact and visibility.
| mandeepj wrote:
| >Linus, as the namesake for Linux also made a huge impact on
| the field... and comes off as somewhat of an uncontrolled
| lunatic.
|
| Ha! Would you consider Musk also as a Lunatic? :-)
| permille42 wrote:
| Musk isn't great enough to deserve such a high title of
| lunatic. More like arrogant madman.
| Izkata wrote:
| Perhaps a Marsatic ;D
| rramadass wrote:
| >Linus, as the namesake for Linux also made a huge impact on
| the field... and comes off as somewhat of an uncontrolled
| lunatic.
|
| What? Linus is one of the most Rational, Direct, No-Nonsense,
| Get Things Done Leader there is. Whenever i hear some self-
| appointed "expert" pontificate on Leadership/Management/etc.
| i always think of what Linus would say/do in that situation.
| People only think of him as a "Technical Guy" but his
| Leadership/Management of something so vital, so huge, so
| distributed, with so many "employees" and with so few
| resources, so many stakeholders is what is amazing to me.
| Nobody comes close.
|
| You really need to take back the "uncontrolled lunatic"
| phrase.
| permille42 wrote:
| 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 that he often is bad at controlling. I myself have
| this issue, and I don't see how one could say he does not
| have issues in this regard.
|
| While it requires some amount of perpendicular thinking to
| be a master of software, having such an attitude and
| working with other people in that way will cause too much
| conflict that is unnecessary.
|
| I think what you are missing in my statement is that I
| consider calling someone an "uncontrolled lunatic" as a
| sort of compliment.
|
| I agree also that he is less of a technical person and more
| of a manager. His skills lie in herding.
|
| On the other hand; Git is a flaming piece of garbage and he
| is directly responsible for its popularity... so... He did
| though reasonably tell people he didn't intend for anyone
| outside of kernel developers to use it. I just wish he
| corrected its deficiencies. Maybe someday he can apply his
| "arbitrary character restrictions are silly" logic to Git
| comments and become less contradictory.
| rramadass wrote:
| 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 person unique. All successful
| companies know this and "manage" their most important
| people accordingly.
| abeppu wrote:
| When is "mastery" a meaningful concept for a field of endeavor? I
| think we wouldn't believe it makes sense to "master" physics or
| math, because the advanced work in those fields focuses on open
| problems. Even if one understands classical physics well, one
| cannot make specific predictions about medium-sized, low-ish
| energy systems like a double pendulum. Can anyone claim to be a
| "master" of an area in which there are such large known gaps in
| everyone's knowledge?
|
| Though in software engineering we have a lot of prior examples of
| successful and unsuccessful projects, we also have lots of open
| frontiers. And in some ways, it's much harder to "know" that an
| engineering approach or paradigm is "right" than it is to know
| that a theorem is true.
|
| How can we make types track the "important" invariances of a
| system? How can we convince ourselves that a distributed system
| can guarantee certain properties, or that a modification to that
| system doesn't break those guarantees? If I build a homomorphic
| encryption system as a service, how would I build debugging tools
| for it? Acknowledging the halting problem and its cousins, when
| can static analysis tools make useful, meaningful predictions
| about programs?
|
| In the bronze age, you could build an impressive stone tower.
| Sometimes you could even make it stay standing. But I don't think
| there were any master civil engineers.
| jgwil2 wrote:
| Very nice analogy to physics/math. I agree: the "best" people
| are always working on the next big problem.
___________________________________________________________________
(page generated 2021-01-07 23:03 UTC)