11 ms·

How does one get close to mastering software engineering?

102 points by sidcool 5y ago

trixie_ 5y ago
Be as young as possible. Know the latest tools and tech. Make sure to point out anything older than 3 years as legacy and should be rewritten. Also know REST and claim anyone who implements it doesn’t actually know REST. But then again GraphQL is far superior so call anyone still using REST a boomer. If software is not using a message bus throw it out. If it’s not microservices make who ever has to work with it feel like shit. You just got hired and/or graduated which makes you the smartest person in the room. Management supports your bold ideas and lack of context. When you eventually create the perfect app that is 95% architecture and 5% functionality with zero comments, leave the company on a high note for them to maintain your masterpiece as you go on to another software company ready to spread your great ideas all over again.
Koshkin 5y ago
Well, no mystery here: “Practice makes the master” is as true as ever. Just start coding, and keep doing it - until you wouldn’t think much of throwing away a 1000-line piece of code you just wrote simply because you came up with a better idea (and because you could write it again if you wanted to, in a few hours).
scott-smith_us 5y ago
There's a quote that I'm too lazy to look up that essentially says software development is the management of complexity. That, more than any other description, has always resonated with me. Any beginner can create a bird's nest of code that is too complex for even the most experienced developers to fully understand. I've been at this for 40+ years now, and if I'm struggling to write something, it's usually not because I don't know how to implement it. It's because I'm trying to pick an implementation that will be simple to understand, verify, and use.
thepra 5y ago
My way has always been building/deploying/administering my own web apps with mixes of old and new tech. I don't know how many other Devs go this way
bigbizisverywyz 5y ago
>How does one get close to mastering software engineering? By doing it, doing it a lot And then listening to, and watching your users use your stuff. They'll teach you more about creating better software than anything else.
Kinrany 5y ago
"Extreme safety" and "extreme flexibility" seem direct opposites of each other: safety comes from having something set in stone, while flexibility comes from being able to change something.
darthrupert 5y ago
Just like you master anything else: ten thousand repetitions.
mbrodersen 5y ago
If you think you can master software engineering (a huge almost infinite field) then you are less experienced and understand things less than you think.
karmakaze 5y ago
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.
- infinite8s 5y ago
  The comment chains where he answers clarifying questions are well worth reading as well. For an example of what he means with CAD/SIM in software engineering: https://www.quora.com/How-does-one-get-as-close-as-possible-to-mastering-software-engineering/answer/Alan-Kay-11?comment_id=217804529&comment_type=2 https://www.quora.com/How-does-one-get-as-close-as-possible-...
comprev 5y ago
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.
- Koshkin 5y ago
  To master swimming does not mean to master the ocean.
  - rightbyte 5y ago
    Ye people seem to have way to high standards for mastering something. Being very good is mastering it. It is hard to be good at programming, but we are not talking genius level standards required to be regarded as good.
  - mbrodersen 5y ago
    Swimming is not a good analogy to software engineering.
    - comprev 5y ago
      Agreed. There isn't really a new way to swim backstroke or new techniques constantly being developed.
Saint_Genet 5y ago
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.
pjmorris 5y ago
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.
- notRobot 5y ago
  I don't really understand that statement, can someone please explain it to me?
  - emi2k01 5y ago
    I had to re-read it multiple times and I'm still not sure. I think he's trying to say that programmers make more comprehensive tools for other engineering fields than the ones they use.
    - mdparker89 5y ago
      If you read through some of Alan Kay's other Quora posts there is some more context behind this. It goes a bit deeper than just the tools we build. We don't think like programmers about the act of programming. Fred Brooks' essay "No Silver Bullet" has a list of past breakthroughs. These are examples of applying programming to programming to ease cognitive load 10x. The essay predicts that we won't see any more of those types of improvements. But we haven't even scratched the surface when it comes to the CAD and SIM tooling for programming. There are many silver bullets left to build.
    - infinite8s 5y ago
      In a followup comment (starting with "That is an excellent question, and I’m pondering … The examples I gave were examples of the kind of math/engineering I was thinking of.") Alan describes a bit more what he means: https://www.quora.com/How-does-one-get-as-close-as-possible-to-mastering-software-engineering/answer/Alan-Kay-11?comment_id=217804529&comment_type=2 https://www.quora.com/How-does-one-get-as-close-as-possible-... The entire comment chain is interesting to get some insight into how he's thinking about Engineering.
peakaboo 5y ago
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?
- AQuantized 5y ago
  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 5y ago
  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...
  - cultofmetatron 5y ago
    single and childless at 36. just frees me up to constantly travel fro place to place without a care in the world.
  - WolfOliver 5y ago
    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.
kodah 5y ago
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.
- wheelinsupial 5y ago
  > “Mastering Software Engineering" smells of professionalization. What's to master? What’s wrong with professionalization?
- nine_zeros 5y ago
  > 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.
swayvil 5y ago
Step 1. Have a thing that you want to make. The rest comes naturally.
irrational 5y ago
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.
ardit33 5y ago
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 5y ago
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 5y ago
  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 5y ago
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-architecture-astronauts-scare-you/ 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 5y ago
  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.
contingencies 5y ago
Write documentation. Especially, document the why.
holoduke 5y ago
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 5y ago
  [deleted]
rcgorton 5y ago
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.
nicholast 5y ago
Build, iterate, refine, enhance, debug, repeat.
deleted 5y ago
[deleted]
AnimalMuppet 5y ago
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.

102 points by sidcool 5y ago

Be as young as possible. Know the latest tools and tech. Make sure to point out anything older than 3 years as legacy and should be rewritten. Also know REST and claim anyone who implements it doesn’t actually know REST. But then again GraphQL is far superior so call anyone still using REST a boomer. If software is not using a message bus throw it out. If it’s not microservices make who ever has to work with it feel like shit. You just got hired and/or graduated which makes you the smartest person in the room. Management supports your bold ideas and lack of context. When you eventually create the perfect app that is 95% architecture and 5% functionality with zero comments, leave the company on a high note for them to maintain your masterpiece as you go on to another software company ready to spread your great ideas all over again.

Koshkin 5y ago

Well, no mystery here: “Practice makes the master” is as true as ever. Just start coding, and keep doing it - until you wouldn’t think much of throwing away a 1000-line piece of code you just wrote simply because you came up with a better idea (and because you could write it again if you wanted to, in a few hours).

scott-smith_us 5y ago

There's a quote that I'm too lazy to look up that essentially says software development is the management of complexity. That, more than any other description, has always resonated with me. Any beginner can create a bird's nest of code that is too complex for even the most experienced developers to fully understand. I've been at this for 40+ years now, and if I'm struggling to write something, it's usually not because I don't know how to implement it. It's because I'm trying to pick an implementation that will be simple to understand, verify, and use.

thepra 5y ago

My way has always been building/deploying/administering my own web apps with mixes of old and new tech. I don't know how many other Devs go this way

bigbizisverywyz 5y ago

>How does one get close to mastering software engineering? By doing it, doing it a lot And then listening to, and watching your users use your stuff. They'll teach you more about creating better software than anything else.

Kinrany 5y ago

"Extreme safety" and "extreme flexibility" seem direct opposites of each other: safety comes from having something set in stone, while flexibility comes from being able to change something.

darthrupert 5y ago

Just like you master anything else: ten thousand repetitions.

mbrodersen 5y ago

If you think you can master software engineering (a huge almost infinite field) then you are less experienced and understand things less than you think.

karmakaze 5y ago

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.

infinite8s 5y ago
The comment chains where he answers clarifying questions are well worth reading as well. For an example of what he means with CAD/SIM in software engineering: https://www.quora.com/How-does-one-get-as-close-as-possible-to-mastering-software-engineering/answer/Alan-Kay-11?comment_id=217804529&comment_type=2 https://www.quora.com/How-does-one-get-as-close-as-possible-...

comprev 5y ago

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.

Koshkin 5y ago
To master swimming does not mean to master the ocean.
- rightbyte 5y ago
  Ye people seem to have way to high standards for mastering something. Being very good is mastering it. It is hard to be good at programming, but we are not talking genius level standards required to be regarded as good.
- mbrodersen 5y ago
  Swimming is not a good analogy to software engineering.
  - comprev 5y ago
    Agreed. There isn't really a new way to swim backstroke or new techniques constantly being developed.

Saint_Genet 5y ago

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.

pjmorris 5y ago

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.

notRobot 5y ago
I don't really understand that statement, can someone please explain it to me?
- emi2k01 5y ago
  I had to re-read it multiple times and I'm still not sure. I think he's trying to say that programmers make more comprehensive tools for other engineering fields than the ones they use.
  - mdparker89 5y ago
    If you read through some of Alan Kay's other Quora posts there is some more context behind this. It goes a bit deeper than just the tools we build. We don't think like programmers about the act of programming. Fred Brooks' essay "No Silver Bullet" has a list of past breakthroughs. These are examples of applying programming to programming to ease cognitive load 10x. The essay predicts that we won't see any more of those types of improvements. But we haven't even scratched the surface when it comes to the CAD and SIM tooling for programming. There are many silver bullets left to build.
  - infinite8s 5y ago
    In a followup comment (starting with "That is an excellent question, and I’m pondering … The examples I gave were examples of the kind of math/engineering I was thinking of.") Alan describes a bit more what he means: https://www.quora.com/How-does-one-get-as-close-as-possible-to-mastering-software-engineering/answer/Alan-Kay-11?comment_id=217804529&comment_type=2 https://www.quora.com/How-does-one-get-as-close-as-possible-... The entire comment chain is interesting to get some insight into how he's thinking about Engineering.

peakaboo 5y ago

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?

AQuantized 5y ago
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 5y ago
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...
- cultofmetatron 5y ago
  single and childless at 36. just frees me up to constantly travel fro place to place without a care in the world.
- WolfOliver 5y ago
  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.

kodah 5y ago

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.

wheelinsupial 5y ago
> “Mastering Software Engineering" smells of professionalization. What's to master? What’s wrong with professionalization?
nine_zeros 5y ago
> 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.

swayvil 5y ago

Step 1. Have a thing that you want to make. The rest comes naturally.

irrational 5y ago

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.

ardit33 5y ago

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 5y ago

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 5y ago
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 5y ago

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-architecture-astronauts-scare-you/ 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 5y ago
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.

contingencies 5y ago

Write documentation. Especially, document the why.

holoduke 5y ago

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 5y ago
[deleted]

rcgorton 5y ago

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.

nicholast 5y ago

Build, iterate, refine, enhance, debug, repeat.

deleted 5y ago

[deleted]

AnimalMuppet 5y ago

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.