Home
Starting Up
Case Studies DB
Products
Ideas DB
Vibe Coding Tools
Subscribe to IH+
Starting Up
Case Studies
Ideas DB
Products DB
Join
16
Likes
7
Comments
Writing code is one thing, learning to be a software engineer is another
by
Zach Ang
https://betterprogramming.pub/writing-code-is-one-thing-learning-to-be-a-software-engineer-is-another-9d5c6fc5d6a8
Well you can’t really be a software engineer without learning to code. That said, there are plenty of “software engineers” that are terrible programmers. And plenty of great programmers that are not software engineers😐
This kinda thing is mostly ego driven gatekeeping and elitist nonsense in many ways. Sure there’s plenty of Design patterns to learn and apply but that often just comes down to experience IMO. Patterns are helpful, no doubt, and Frameworks are used to encourage those patterns anyway so most people will be corralled into using patterns without even knowing it when they start learning to code.
Many people here would have heard about the single page PHP web apps that generate north-of $350k/year. There’s probably patterns implemented within those pages that the author invented and understands that others wouldn’t recognise - does that matter? It doesn’t appear to, if earning a living without getting a “real job” is your goal. 🙂
Totally! And there's nothing wrong with not knowing the nuts and bolts.
I think that what the article is focusing on are those who may be looking to break into the business via other means than just indie hacking. Perhaps looking to join a startup or a larger company.
A lot of my experience as a former lead engineer was that I was spending the majority of my time learning how to effectively communicate with other engineers. This is where these patterns and principles really start to come into play. You start to notice commonalities in systems that scale and you slap some labels on them, so that everyone has a reference.
Suddenly you have a common language to speak, and you can much more easily direct a team down the right path to enable the product to be built effectively at scale.
A lot of the theory can be exceptionally boring. Especially if you simply aren't all that into computer science.
But when you're working with a team of developers, you're gonna want someone at the head of the team with all of this knowledge under their belts. It really makes things so much easier to manage.
To me I interpret this as the author advocating for programmers to understand the fundamentals of all data structures so they are capable of writing code in a variety of languages. Once you understand the fundamental data structures, you are capable of being throw into a different situations and coming out with a solution. Programmars who have a purely practical understanding of code probably don't understand data structures as well as SWEs, and for this reason are more suited to maintaining their own projects, but they aren't capable of working on projects they haven't built themselves. This is fine, and not a problem for an indie hacker, but if you are looking to be an employee then it will pose an issue down the line.
In the end, figure out what path your going down and then plan accordingly. If you want a 9-5 and to indie hack, you should learn data structures and algos. If you just want to indie hack, forget the data structures and algos practice and skip straight to figuring out how to make your product real and not theoritical.
First time someone mentioned "dependency injection" to me I felt like an idiot. Turns out it's just the thing I've been doing for 5 years with a term that just sounds way more fancy than it is.
Yeah, applies to so many terms in programming that are just fancy ways ['conventions'] to explain something simple. I can vividly remember how many times I've been virtually scoffed at on Stackoverflow for not using the right terms.
you gotta start somewhere
Creativity is very important.