61–70 of 290 posts
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 applica…
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 applica…
Is this a parody?
Someone who is good at mental models.
I think of Linus, Lars, Anders, TJ, Rich, etc
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.
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]
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.
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
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 enginee…
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?
- 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.
Earlier quoted context omitted.
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?
Sticking around long enough to see a big mistake bite you is sometimes better for your growth than swapping jobs.