[HN Gopher] How does one get close to mastering software enginee...
___________________________________________________________________
How does one get close to mastering software engineering?
Author : sidcool
Score : 61 points
Date : 2021-08-24 06:16 UTC (16 hours ago)
(HTM) web link (www.quora.com)
(TXT) w3m dump (www.quora.com)
| karmakaze wrote:
| Good food for thought.
|
| > Going deeper, most software people are just trying to do FAB
|
| This is for the most part true, but I think it's better to
| highlight and promote the other areas being worked on.
|
| > and most of the tools are FAB tools -- there is very little CAD
| and even less SIM in "software engineering".
|
| Also true. What I see as the CAD and SIM work is being done in
| ecosystems, we are experimenting with various FAB toolchains,
| effectively each ecosystem is a CAD experiment, and the entire
| field is the SIM. The proliferation of programming languages
| exploring paradigms, source control, package distribution, build
| systems, etc, is moving the needle.
|
| One thing we don't do well is identify, adopt, and refine the
| better ones sooner.
| pjmorris wrote:
| Note: Answer in the linked post is by Alan Kay, so very much
| worth pondering.
|
| Grist for the mill:
|
| "It's worth noting the deep irony that the new computer tools for
| the engineering disciplines are almost always more comprehensive
| than the ones found in use by computer people for writing the
| programs! (There are a lot of "black screen simulated card-deck-
| glass-teletype" screens in use, in gross contrast with e.g. how
| something in EE or ME is designed and made today.)"
|
| EDIT: Added parenthetical quote from Kay's post to explain what
| he considers ironic.
| eternalban wrote:
| Earlier he had noted that engineering is informed by science,
| so not sure why he thinks it ironic. The science behind
| engineering disciplines is orders of magnitude more developed
| than the science informing writing software.
| JohnWhigham wrote:
| Yup. It's just applied X. Mathematicians create the theories,
| engineers use the theories to create the tools, developers
| use the tools to create the products (roughly).
| pjmorris wrote:
| I added his parenthetical comment. I think he means, for
| example, that we could probably do better than vi, emacs, VS
| Code, or even IntelliJ for supporting our thinking as we
| write software.
| yodsanklai wrote:
| A big part of software engineering is being able to work with
| others. Software projects consist of people from different
| backgrounds, with different personalities and skills, working
| with a variety of constraints.
|
| This involves a lot of soft skills. Also, we can't always apply
| proper engineering techniques and we need to be able to
| compromise. Moreover, all projects are different and the field is
| changing fast. I don't think all of this can ever be mastered.
|
| That being said, to me, a good SWE is someone who has a good
| grasp on the fundamentals of the field (algorithms and data-
| structure, compilation, operating system, database, fluent in all
| programming paradigms), who is a hacker (enjoy programming), can
| work on big legacy code bases with other people under pressure,
| has designed complex projects from scratch, is able to write
| tests and documentation, isn't religious about tools or
| programming language, can navigate corporate bullshit.
| comprev wrote:
| It's like "mastering" any continuously developing subject - an
| impossible feat due to the sheer size of it.
|
| As others have mentioned, the further I too progress in a
| technical career, the more I realise how little I truly
| understand in the grand scheme of things.
| rcgorton wrote:
| Utterly impossible. There are absolutely ZERO objective targets.
| Processes override, and are incredibly non-standardized. "Agile"
| is useless/dead (Dig into the issue) and a total time waster, but
| it is unfortunately popular by SW developer managers. SCRUM is
| frequently buffalo excrement. At best. The principal problem is
| that management driven process is not about goals, it is about
| meeting MANAGER ideals.
| Saint_Genet wrote:
| This may sound trite, but I believe the first step towards
| masterhood in 2021 is to realize that you can never master a
| whole field of engineering.
| swayvil wrote:
| Step 1. Have a thing that you want to make.
|
| The rest comes naturally.
| contingencies wrote:
| Write documentation. Especially, document the _why_.
| AnimalMuppet wrote:
| First, you can't. No one can. So don't feel bad that you
| can't/haven't/didn't/won't.
|
| Second, what is "mastering"? It's not being able to crank out
| leetcode problems. It's much more being able to see the upsides
| and downsides of various architectural, design, and
| implementation decisions, and to not make the wrong ones.
| ardit33 wrote:
| Mastering Software Enginerin is like someone saying 'how can i
| master all Medicine'. It is impossible. Sure, all doctors will
| have a basic and good knowledge about general medicine, but at
| some point you have to specialize in order to provide the deep
| care is needed.
|
| it is the same with engineering, there are so many subsets of it,
| that it is impossible to be great at all of them (eg. backend,
| databases, mobile dev, front-end, embdeded systems).
|
| In order to became good, you have to became good at programing,
| and general algorithms and data structures, as they tend to be
| universal. The pick an area or two, and become good at it by
| building tangential things on it.
| onion2k wrote:
| There seem to be two main schools of thought about what "good
| software" is. They're not antagonistic, you can have both, but
| few engineers seem to want to. The first idea of "good software"
| is the software engineering approach. The focus is on writing
| clean code that's simple, understandable, fast, and correct. This
| is the most common one. The second is that "good software" is the
| "application design" approach, with the aim to deliver a final
| product that solves the user's problem well. The focus is on
| things like UX, design, correctness (again) and timeliness (eg
| getting features out the door so people can actually use them).
|
| To truly master software development you need to understand both,
| and practice both. Writing the most perfect code in the world is
| ace if your customer can wait. Building the most beautifully
| straightforward app is great if it also works properly.
|
| You can't be a productive, useful developer if you ignore one or
| the other school of thought.
| dasil003 wrote:
| Oh this is billiantly stated. It is fairly rare to have both
| these traits, and I've even seen in large orgs where ostensibly
| talented engineers have _neither_.
|
| To be more specific, some engineers/teams are completely driven
| by artificial internal metrics (like ticket counts, point
| estimations, etc) without a concern for technical debt, or the
| success of the product. Instead they operate sort of like the
| Chinese Room thought experiment, where they translate literal
| requirements from upstream, but don't actually think about what
| that means to a user. Instead they just plug it into known
| concepts in the system, and wait for the bug reports to come
| in, then churn through those. Over time complexity builds
| without hope of refactoring because there is no one to advocate
| for simplifying the approach as it requires both internal and
| product compromises. Eventually a tipping point is reached
| where no competent engineer will touch the system and the
| question becomes how long business inertia will allow the
| paychecks to keep clearing.
| mathgladiator wrote:
| There is a level of mastery, but it is borderline useless. I've
| been called an architecture astronaut (ref:
| https://www.joelonsoftware.com/2001/04/21/dont-let-architect... )
|
| And the thing here, software is simple. You take bits in, do
| stuff, and then its bits out. State machines there. Disks over
| there. Algorithms in hand. There is no real end to understanding
| all the details, but the game is well understood in a very
| reductive manner.
|
| There is the game that we study which is making these infernal
| machines do useful things. Then, there is the meta game of
| getting humans to do things with these infernal games. These
| games are infinite and mastery demands you to see them for the
| games that they are.
|
| In this, there is no plateau. You can operate with peak resources
| to explore, but the game is the game to play.
| ozim wrote:
| Yes and no.
|
| I don't agree to describe it as games.
|
| It is just reality and life as is.
|
| You should understand high level abstractions that run our
| lives or software.
|
| But then as well you should understand that a lot of people are
| not having time/will/capacity to understand high level
| abstractions that are interesting for you.
|
| I get angry mostly because people are not caring to understand
| - that is why everyone wants to build greenfield projects
| instead of maintaining existing ones.
|
| It is just like person trying to open a lock with key for the
| first time on the old gate, they try to force it while they
| could wiggle the key a bit to find the correct position.
|
| I owned couple of old cars and if you put a little bit of care
| and understanding they will drive perfectly well, even with
| check engine LED on :)
|
| The same with team of people - don't expect that they will
| understand your "perfect world" just try to wiggle a bit so you
| can improve things enough so they work. Because what is
| important is getting job done and not having "prefect" world.
| holoduke wrote:
| The one and only skill needed for software engineering is problem
| solving. By searching, by knowing, by copiing, by inventing.
| Doesn't matter. There is nothing more than that.
| [deleted]
| peakaboo wrote:
| You are much more likely to burn out then to master it. Look at
| the age groups in software development. Most people get out of it
| before 40 because it's such a draining profession.
|
| Can you really even master something like software development
| where things change dramatically almost every year?
| knuthsat wrote:
| learning the underlying principles of things makes the changes
| look less dramatic.
|
| after some point there's not much one needs to learn to be
| productive.
|
| I feel no pressure not knowing vue, django, fp-ts, rxjs, Rust,
| Zig, C++20. Rarely there's something you can do with new stuff
| that you can't do with old.
| AQuantized wrote:
| Part of this is probably that it's such a young profession.
| Most people I work with are quite a lot older than me
| anecdotally, however.
|
| Even though the frameworks and languages in vogue change
| rapidly, the patterns and logic seems to be very similar. When
| I have to learn a new language now it's more a matter of
| researching the syntax and idioms rather than learning from
| scratch.
| jmkni wrote:
| I think that at least partly has to do with life circumstances
| changing, people get married, have kids, etc and have less time
| to spend practicing, reading.
|
| I'm 32 now, have been doing this since 20, and (I think/hope)
| mostly kept up to date, but I'm also single/childless lol.
|
| Also, as you move up, you inevitably end up managing/mentoring
| younger devs (unless you have terrible people skills or
| something), meaning you spend less time actually coding, this
| also makes it more difficult to keep up to date (in detail, you
| still know what's going on, but have less experience
| implementing).
|
| To be fair, terrible people skills could also apply to still
| being single/childless at 32, I hope not...
| WolfOliver wrote:
| you are in professional software engineering since you are
| 12? Learning to program is not the draining part it is the
| fun part. Dealing with people is the hard part.
| jbarberu wrote:
| Doing this since [age] 20
| rjbwork wrote:
| They said since 20. Meaning 12 years.
| yourapostasy wrote:
| _> ...as you move up, you inevitably end up managing
| /mentoring younger devs (unless you have terrible people
| skills or something), meaning you spend less time actually
| coding..._
|
| You can somewhat mitigate this if you want to still keep your
| hands in the code by finding the intersections of two or more
| tech stacks that take two or more others to even approach.
| The inevitable impedance mismatch between say two stacks
| means that one person familiar with both is usually far more
| effective than two people who have to feel their way through
| the mismatch.
|
| As a senior in this position, you often get to do the "fun"
| parts of throwing together a proof of concept, validate your
| mental model of the impedance mismatch, outline the details
| to iron out (usually known-complexity work like documenting,
| hooking up to various plumbing for unit testing, tracing,
| logging, monitoring, internationalization, _etc._ ), and go
| on to the next fire to help put out.
| jmfldn wrote:
| The fact that most engineers are young is much more to do with
| the numbers in the profession doubling every five years in the
| last twenty years imho. If you were an engineer twenty years
| ago, there are now sixteen times more engineers. Your peergroup
| is going to look pretty small therefore. All of these younger
| engineers are going to get older too of course, and the demand
| won't keep on growing at this rate, so inevitably the ratio of
| young vs old devs will even out.
|
| Sure, some devs become managers but there are only so many
| managerial jobs. Some also drop out but not in vast numbers.
| From my own experience, I see quite a few of devs my age (40)
| and older. For the most part we're senior engineers, some are
| managers. I don't know anyone who's left the profession. Just
| my anecdotal evidence but I do feel this phenomenon is
| overstated.
| rubicon33 wrote:
| And what about your 50s, or 60s? When do you plan to retire?
| The "average" retirement age is what, 65? Do you plan to code
| until then? If so, are you fairly stable in what
| language/domain you're coding for, or are you learning
| constantly?
| jmfldn wrote:
| Good questions. I'm not 100% sure, but currently I plan to
| be an engineer until I retire which I guess will be around
| 65. My goal will be to wind down later in my career though,
| work less than a 5 day week and go for contract /
| consulting kinds gigs from 50s onwards ideally. Right now
| I'm happy just being on the payroll doing a 9-5 gig. The
| stability suits me well at this point in life.
|
| I'm a Scala developer working on fairly typical,
| distributed systems / web apps. I have no plans to stop
| Scala since I love it but any JVM language would suit me.
| I'm also into system design / architecture in the
| distributed system, "reactive" architecture domain. Those
| are the systems I tend to work on, massive web apps
| consisting of many microservices.
|
| I'm always learning and trying to be on the edge of my
| comfort zone which is key I think. If I'm not messing with
| Scala then I'll be learning more about Kafka, Docker, SQL /
| Mongo, Terraform, AWS and a bit of Linux.
|
| I'm far from a master in any of these things and I don't
| think I'll master many which is fine. I know enough to do
| my job and I keep on learning but the breadth of what I
| have to know is too broad to master it all. My true passion
| is programming, particularly functional, and I would love
| to master that for myself as much as anything. I guess you
| have to chose where to go deep and where to go for breadth.
| You can't master it all!
| rubicon33 wrote:
| Thanks for your reply, I'm always interested in hearing
| about how other developers are choosing to tackle this
| tough career question about depth v.s. breadth.
|
| Scala is an absolutely awesome language, one that I love.
| I've had some of the best times building distributed
| systems with Scala + Akka and frankly would have loved to
| lean into that ecosystem and become a master of it.
|
| Unfortunately, the market for that specialty is
| relatively small when compared to the broader software
| engineering market. I worried about specializing in a
| language that was niche. Compare it to, for example, the
| need for React, React Native, or even simply Java.
|
| I have chosen to be very flexible in my career and learn
| many languages, across many domains. This, I think, is
| the source of some of my feelings of burnout in my 30s.
| It's just a never ending grind. When I do find a domain
| that I really love, like firmware, or Scala... I'm forced
| with the difficult decision of depth v.s. breadth and
| breadth always seems like the "safe" route, especially if
| you're willing to jump between frontend or backend and
| whatever is the flavor of the week as far as frameworks
| go.
|
| I've heard horror stories of engineers who dug into their
| tech stack and never really kept pace with the industry,
| only to find themselves disposable, and inflexible, in
| their 40s and 50s. Whether or not those anecdotes are
| worth worrying about is certainly up for debate. I tend
| to be a worrier so, it's no surprise I've chosen the safe
| route.
| yodsanklai wrote:
| > Most people get out of it before 40 because it's such a
| draining profession.
|
| Most of my team are 40+, we're doing fine.
|
| > Can you really even master something like software
| development where things change dramatically almost every year?
|
| This is a good point but things don't change that fast.
| commandlinefan wrote:
| > more likely to burn out then to master it
|
| I think you probably meant "than"... although that may be
| profound the way you spelled it.
| rubicon33 wrote:
| I have been seriously wondering about this. I'm mid 30s
| developer who has (because of jobs) switched domains multiple
| times over the last 10 years.
|
| I've learned 7 programming languages, COUNTLESS frameworks
| (both backend, and frontend), across many different domains...
| frontend web, native mobile, hybrid mobile, backend, even
| dabbled in firmware for a few years. All of these in a
| professional context, where I was shipping real live code.
|
| If there's been one constant in my career it's been change.
| Change is constant. I can absolutely expect that in a given ~3
| year timespan, I will need to learn a new language, domain,
| framework, etc.
|
| The result is absolutely that I feel like a jack of all trades,
| but a master of none. I can pick up new languages and
| frameworks quickly, but I don't ever feel intimately familiar
| with any given language or framework or domain. I don't feel
| like a "master" of anything other than, perhaps, mastering the
| ability to learn new . It sucks.
|
| Perhaps not coincidentally, I've struggled with feelings of
| burnout. Looking back on my career over the last 10 years, it
| feels like a constant sprint. Of course I'm a better developer
| today than I was 10 years ago, but I know that the future only
| brings one thing: New technologies, new frameworks, new
| languages. I will need to learn those, and only a fraction of
| my current knowledge will apply.
|
| It's hard not to feel like you're treading water in this
| industry. I can learn anything, but for long? For how many
| years, or decades, am I willing to do this? It feels like I
| need to either accept that this is the reality of this
| industry, that the biggest skill I can have is willingness and
| ability to learn, or, accept defeat.
| MattGaiser wrote:
| I graduated two years ago and I feel behind not knowing Vue and
| Elixer, never mind things like Rust.
| ravi-delia wrote:
| Don't get me wrong, Elixir is one of my favorite languages,
| but I don't think you'd be behind for not knowing it. Even
| functional programming as a whole isn't widely enough adopted
| that people who aren't familiar with it are behind.
| cactus2093 wrote:
| > it's such a draining profession
|
| I truly can't understand thinking this. I've worked in software
| engineering for over 10 years now, at a wide range of companies
| from tiny startups to large tech cos. We easily make 2 - 5x
| more than the median wage, work indoors in a comfortable
| environment sitting (or standing, for anybody who prefers) all
| day with high end ergonomic equipment, often get unlimited
| vacation time, can often choose not to work more than 8 hours a
| day if we don't want to, and all while doing something that
| many of us got into simply because it was a fun and engaging
| thing to do. And just in the past year millions of software
| engineers have gotten the option of doing this fully remotely,
| freeing them up to live anywhere they want and never have to
| commute. What a time to be alive!
| [deleted]
| decebalus1 wrote:
| Read some of the comments in this past thread
| https://news.ycombinator.com/item?id=27821392 to understand
| this better. I've also been working at this for well over 10
| years and I do agree that overall this profession is
| draining. I often need 'hard resets' between jobs, it's hard
| to compartmentalize work and regular life when you brain is
| constantly thinking about 'the system'. I have experienced
| burnout a bunch of times. It's not pretty. Add the new trends
| of making devs do oncall because frankly everything is
| online, tech interviews becoming the coding Olympics, the
| incentive structure in an organization making people cut
| corners or backstab coworkers to get ahead, it's not hard to
| understand how someone would consider the profession
| draining. This is from the perspective of someone who worked
| both in small and big corps on the west coast.
|
| Comfort doesn't have a lot to do with burnout or job
| satisfaction unless you're coming from a blue collar mostly
| manual job.
|
| > many of us got into simply because it was a fun and
| engaging thing to do
|
| That's one of the problems. For a lot of folks, it was
| exactly that 'was a fun and engaging thing to do' and then
| you get do it in the context of office politics, tight
| deadlines, need to sacrifice professional ethics and ship
| something half-assed because that's what the business needs,
| etc.. These things, repeatedly chip away at your happiness.
| Would you be more unhappy without the ergonomic equipment and
| all of that? Most likely yes. But ping-pong tables and the
| unlimited vacation (which is at the discretion of your
| manager anyway) doesn't always compensate for shit work or
| the nervous breakdown from having to sit on an incident
| bridge for 4 hours...
|
| I need to admit, I love my job and I love this profession.
| But I do understand when people say it's draining.
| cactus2093 wrote:
| Most of this is true of any office job though.
|
| Oncall is somewhat unique, and that can be tough, but if
| it's particularly rough and there is nothing you can do to
| improve it that's a good sign to find another company (or
| perhaps another specialization within programming) because
| it doesn't need to be that way. Incident response is mostly
| a self-imposed stress, and I've found it to be something
| that you can learn to manage better and not let it affect
| you so much, by being prepared with good playbooks, as well
| as accepting that it's not the end of the world and that
| all you can do is try your best.
|
| I'm not denying that life itself can be draining. Working
| any type of office job can be draining. I just don't see
| how programming is particularly more draining than all the
| other jobs people do.
| brailsafe wrote:
| Well, not to be reductive, but what have you done in that
| time, and for who? You said a lot about conditions of work,
| and that's great stuff, but often times a McDonald's employee
| has more visibility into where their work goes than a
| developer making stupid widgets to increase their numbers for
| the week. A construction worker can point to a house and say
| "I built that foundation, it'll be there for 20 years, during
| which someone will live in it"
| doomroot wrote:
| Sounds like you need to quit your job. I hear they're
| paying new hires a lot.
| cactus2093 wrote:
| I've done lots of things over the years, sometimes grown
| sales by millions of dollars, sometimes taken a brand new
| thing from 0 to 1 and get it out to the first users, and
| I've experienced the satisfaction of solving a problem for
| happy customers. Not always, mind you, I've also seen
| companies have to downsize or shut down when their lofty
| goals didn't quite pan out. But that's the beauty of being
| in this field these days, there are so many different kinds
| of companies out there to choose from.
| kodah wrote:
| I've been programming since I was about nine. I still love
| writing software as much as I did the day that I figured out that
| you could compile code. Corporate code gives me the kind of feels
| that I see in other comments here about burnout. I often tell
| folks that when I go to work I am a shell of the man I really am,
| git clone --depth 1 if you will. It isn't necessarily the code
| itself that bothers me; it's the incentive structure, it's the
| way managers and executives commonly lie or manipulate you with
| stories and narratives, and the politics. It's like I can see all
| of that in the actual code. I can see where someone stayed up way
| too late, or compromises were made with an overzealous executive
| or manager. I came into engineering because I loved to code, I
| stayed for the money, but when this career is long gone I'll
| probably still tinker with code.
|
| "Mastering Software Engineering" smells of professionalization.
| What's to master? Algorithms, data structures, patterns? To me,
| the mastery of software engineering is learning to learn and
| identifying what things to learn when. There will be a thing
| after coding, and the same kind of people will inhabit that job,
| I suspect.
| nine_zeros wrote:
| > it's the incentive structure, it's the way managers and
| executives commonly lie or manipulate you with stories and
| narratives, and the politics. It's like I can see all of that
| in the actual code. I can see where someone stayed up way too
| late, or compromises were made with an overzealous executive or
| manager. I came into engineering because I loved to code, I
| stayed for the money, but when this career is long gone I'll
| probably still tinker with code.
|
| As the saying goes, "I would sling code all day for free. It's
| the other bullshit that I need to be paid a lot for."
|
| Management really should be thin layers in software companies.
| Instead, it is the only way to progress in the career ladder
| sometimes. Every manager in this thick layer wants to somehow
| show that they are doing something. They do this by creating
| more bureaucracy and busy work (but only for others).
|
| Meetings actually counts as work for them. When they have a
| hundred meetings a week, they are happy and proud that they
| worked so much. For engineers/developers (or anyone producing
| the actual output), meetings are an imposition.
| UnpossibleJim wrote:
| What's the saying? There was someone who painted the Mona
| Lisa and there was someone who made the McDonald's logo, but
| only one of them got paid. Something like that, I'm sure I'm
| butchering the saying. You have to make a living, but you can
| still code for fun. They're different types of coding.
| onion2k wrote:
| _For engineers /developers (or anyone producing the actual
| output), meetings are an imposition._
|
| This is true for the sort of engineers who have no input on
| what is being built. Once you get to the level where you're
| making architecture decisions you need meetings in order to
| discover what to build.
|
| My advice to any developer who dislikes meetings and sees
| them as an imposition is to find a way to appreciate them, or
| stay near the bottom of the food chain.
| nine_zeros wrote:
| I am not talking about discovery meetings set by engineers
| to discuss with other engineers. I fully realize no one is
| an island.
|
| The meetings I am talking about are daily stand-ups,
| presentation for management (why don't you make some slides
| that we can present to the VP), the random late meeting set
| by a Product Manager because they wasted too much time on
| "other commitments" and could only get back to this one
| now.
| coldacid wrote:
| If your discovery meetings are just engineers talking to
| other engineers, you're doing discovery wrong. The people
| building the product are *not* the only stakeholders.
| [deleted]
| nine_zeros wrote:
| I don't think you have been exposed to all kinds of
| software engineering.
| dragonwriter wrote:
| > _For engineers /developers (or anyone producing the
| actual output), meetings are an imposition._
|
| > This is true for the sort of engineers who have no input
| on what is being built.
|
| It's true for everyone who isn't gratuitously satisfying a
| desire for social dominance displays.
|
| > Once you get to the level where you're making
| architecture decisions you need meetings in order to
| discover what to build.
|
| Some meetings are necessary, all meetings are impositions.
| If you are at the level where meetings are serving your
| individual needs and you are calling them, you need to be
| very cognizant that they are _still_ impositions, and not
| just for engineers. And it 's good to view even your own
| meetings as a kind of self-imposition to be optimized and
| minimized _in your own interest_ , as well as those of the
| other people they are imposed on.
|
| > My advice to any developer who dislikes meetings and sees
| them as an imposition is to find a way to appreciate them,
| or stay near the bottom of the food chain.
|
| IME, people high up in the food chain tend to also view
| meetings as impositions, and people who _don 't_ view
| meetings that way tend to get negatively noticed for it
| from above, below, and laterally.
| [deleted]
| actually_a_dog wrote:
| > I've been programming since I was about nine. I still love
| writing software as much as I did the day that I figured out
| that you could compile code.
|
| > [...]
|
| > I came into engineering because I loved to code, I stayed for
| the money, but when this career is long gone I'll probably
| still tinker with code.
|
| Funny, this is my exact story as well. I still remember
| independently re-inventing the bubble sort algorithm when I was
| around 10, not knowing you could do better. :)
|
| As for the topic of "mastering software engineering," I'm not
| sure that's possible. The stuff we learned in school about hard
| algorithmic problems is not what we deal with on a daily basis;
| or, rather, it's not what 99% of us deal with.
|
| What I mean is that most software engineering problems are
| social problems. Most software only has meaning in a social
| context. That is, its utility and correctness are subject to
| social forces [0]. This is true any time more than one person
| is involved in developing or using a given piece of software.
|
| In my experience, this has been true for almost every bit of
| code I've ever written, the exception being some fancy
| numerical integration code I worked on in grad school for a
| bit. Even then, I could probably argue that there was a social
| component to it, since I was building upon the work of previous
| grad students.
|
| IMO, the most important skill a software engineer can have is
| knowing how to identify the social forces behind the software
| he or she is being asked to write. You aren't paid to write
| code; you're paid to solve problems, and, as I said, all the
| real problems are social. Sometimes you can do that _without_
| code, or, at least without writing _additional_ code, and those
| solutions are often the best solutions to the problem.
|
| And, once you've written code, as you said, you're leaving
| behind an artifact for future software engineers to see. You're
| communicating with the future every time you write a line of
| code. Since you don't know how the future is going to interpret
| what you've written, you should write it as clearly as
| possible.
|
| It is in this way that I believe software engineering really
| isn't much like engineering _per se_ , but more like writing a
| book. Except that it's a book with potentially hundreds of
| authors.
|
| ---
|
| [0]: If you don't believe that, then, how do you explain the
| existence of product managers? ;-)
| nicholast wrote:
| Build, iterate, refine, enhance, debug, repeat.
| irrational wrote:
| I'm not sure it is possible. There is far far too much to be
| familiar with, much less master. The more I learn (and I've been
| doing this professionally for almost 23 years) the more I realize
| I don't know. I'll retire in about 15 years and I don't think
| I'll come anywhere close to mastering software engineering by
| then.
___________________________________________________________________
(page generated 2021-08-24 23:01 UTC)