Can you please give insights into "Studying topics from first principles instead of corporate documentation"? Studying topics from first principles?

An example of this could be Postman or your favorite Git GUI.

You can also learn HTTP networking and curl, as they are the underlying principles of Postman, and learn Git graphs instead of using a Git GUI tool.

Next time you're confronted with a problem, instead of starting with "let's solve this with library X or framework Y," begin by asking "what are we trying to solve?" and then explore multiple options to solve that problem.

A technique I often employ is to first ask what the complexity of the problem is, then evaluate the complexity of each potential solution. For instance, the goal might be implementing automatic deployments, but the solution became way more complex than the original stated goal.

The technique often stil lead you to popular solutions, but it could also point you toward simpler, less conventional alternatives. Sometimes even eliminating problems by side stepping them completely.

I still don't get it. I don't care about reducing complexity, I care about reducing complexity that will be me of my teams problem, and even then, it's not my top priority, getting rid of potential manual error is more important.

A pencil will always be simpler than all of Keep's infrastructure, but it requires vastly more skill and attention than a cloud notes app, to the point where it's primary benefit seems to be as a form of mental exercise.

Thank you : )

Sure, I've been doing a lot of full-stack web development lately, and I found that reading chapters from the textbook "Computer Networks" by Andrew Tenenbaum as a primary source to be far more enlightening about how networks operate, than reading any of the hottest frameworks documentation on how they work under-the-hood. Corporate documentation tends to be more about giving off the vibe of competence, as opposed to being actually informative. They want to make it look like their tool/framework is easy to learn by offering false senses of understanding, instead of the deep understanding provided by textbooks. There are exceptions, but they seem to be growing more and more rare. Compare man pages for old CLI tools versus documentation for frameworks like Next.JS, which tends to gloss over important implementation details that might make you a better overall developer (instead of a framework wrangler).

On the side, I'm trying to enhance my knowledge on embedded systems as well, and picked up the book "Making Embedded System" by Elecia White. I have learned so much in just the first few chapters, even though I worked on an embedded software project for a full year recently. This has served me well, because previously my understanding of embedded systems was more of at the level of an Arduino, rather than an embedded developer. Arduino is fantastic for getting your feet wet, but it does hide away a lot of slightly complicated details (that are not actually that hard to learn with a little effort).

I would basically say, always prefer lengthy and somewhat dry textbooks over superficial and meme-heavy blog posts (or worse, YouTube videos). Learn the subject as if you only have one shot in your career to learn it, and have to learn a permanent representation of the subject that can last decades. Entertaining corporate docs, blog posts and videos are like a sugar-heavy diet for the mind, you'll feel energized at first, but eventually become sick from lack of deep understanding of anything

In a twist of irony, here is a blog post that explains this idea reasonably well - https://archive.ph/XSPRr

Here's a canonical blog post (again, the irony) on why understanding subjects deeply is important - https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

The better "Framework wranglers" usually eventually learn the "leaks" as part of the abstraction's API, and learn to be comfortable not trusting anything.

TCP can fail, but so can my own totally deterministic code I only think I understand. Or more likely, I trip and fall and break the Ethernet cable and the whole thing fails.

My job is to make the final result reliable anyway, even knowing the thoughts in my own head are not trustworthy. Even if I knew anything about proof theory I could still make a mistake with a mathematical proof, and simplicity can't stop it. Left and right are fairly simple concepts and I've mixed them up so many times.

A lot of devs think in terms of trust and quality, and are so quick to assume entire subsystems are perfectly fine, whether it's because it's a high quality thing from a trusted vendor, or because it's simple and they did it themselves and feel they understand it.

It's just like in real life, how people seem totally sure they won't trip and fall or drop what they're holding. I'm used to understanding my own hands as unpredictable, so I guess that's why I like tech.

It's less about avoiding mistakes and more about predicting and planning for mistakes.

> It's less about avoiding mistakes and more about predicting and planning for mistakes.

Totally agreed

Thank you, good sir : ) for the explanation.

That seems like stuff that would increase productivity for a computer scientist or someone working on very novel algorithms, but might not be quite as relevant to an integrator dev at a crud shop.

I interpreted the original question as how to be good at this career of software engineering. If someone wants to hack together some legos and log off at 5pm every day then don’t do anything I said, but also don’t expect to experience the exponential productivity growths enjoyed by devs who take their careers seriously. And subsequently, don’t expect to have a job you enjoy in this industry for very long

For the record, my day job is in fact more of an “integrator” than a computer scientist, but I still find value in every learning principle I laid out.

With the growth of AI, you might be right, more and more jobs are going to require deeper knowledge. It's kind of scary when I'm using codeium and it writes exactly what is would have, if I had no time constraints at all, because it means a lot of what I do is incredibly predictable.

But there's still a lot of skill and possibility to take your career seriously with hacking together Legos, if you want to make your Lego thing reliable and maintainable, and I don't think they're exactly the same skills as someone like a compiler writer or suckless dev needs.

I'm not dealing directly with data regularly, I don't need to awk things, but I do need to know about the oddities of high level frameworks. Knowing awk might help somewhere, but it's not as essential as knowing CSS browser compatibility issues.

A lot of the time I don't even make decisions based on technical factors, they're made for me by social factors and I can either make it work or fail.

I've been at places where git branches were out of the question,the uphill battle to convince everyone to learn them was probably not happening.

You’re right, I probably phrased that poorly. There are multiple ways to “take a career seriously”, and the one I described is just one way. I do think it’s the appropriate way for the software engineer individual contributor path, specifically