Transitioning from Frameworker to Software Engineer

Engineers should prioritize deep programming knowledge over frameworks to enhance their software development skills.

### From Frameworker to Engineer: Embracing True Software Development
* 🚀 This article advocates for self-improvement in the software development field, urging individuals to **identify as engineers** rather than merely **framework users**.
* 💻 The author highlights the shift from defining oneself by programming languages to frameworks, emphasizing that being a **"React developer"** is not sufficient; one should strive to be a **software engineer**.
* 📚 While frameworks can aid in development, the article stresses the **importance of understanding the underlying programming languages and principles** to avoid being a "**frameworker**" who lacks depth in knowledge.
* 🛠 Frameworkers often rely on abstractions provided by frameworks, which can lead to a **superficial understanding of programming**, hindering their ability to **solve problems effectively**.
* 🔍 The journey from frameworker to engineer involves not only reading and writing diverse code but also gaining a **deeper understanding of software design principles and practices**.
* The author encourages aspiring engineers to **embrace challenges** by working on projects **outside their comfort zone**, thereby enhancing their **coding skills and adaptability**.
* 📈 Ultimately, the article asserts that true engineering requires **balancing stability and change**, anticipating software needs, and being **prepared to evolve with the technology landscape**.
* 💡 "Becoming an engineer doesn't have to be the end, but it's a **great place to be**," underscoring the **continuous journey of learning and improvement** in the field.

Be an engineer, not a frameworker. This article is a plea for self-improvement. You can do this. Be an engineer. I love this take already; I'm loving it. I can feel myself loving it. I always say, 'There was a time period

in life where people would define their role as a software developer by the language they chose. I'm a JavaScript developer,' right? But that has so much been obliterated that now, at this point, people say, 'I'm a React developer.' That's somehow a framework that calls itself a

library is worthy of being the type of developer you are. It's not. It's crazy that you say you're not a framework developer; you are a software engineer. Learn how software works. Be an engineer and stop caring so dang much about these things. Also, use HTMX because it's

the greatest. I'm an HTMX developer, by the way. As always, caveats first: engineers, uh, definitely should, and do, use frameworks. There are beautiful bits of engineering that get stuff done in a maintainable way. Frameworks are not the enemy of this article. Bravo, Frameworks! Okay, enough of

that. Good take. Uh, sorry, what are frameworks? Frameworks are software tools that provide a scaffolding to complete software projects of a particular type. So if you want to write a single-page web app in TypeScript, use HTMX because there's there's nothing else. You don't have to

do it from scratch because there's HTMX. Uh, what do you—let's see—want to do some machine learning in Python? Allow me to introduce my friends. Want to write a backup in C#? I don't—what the hell is C#? I don't

Even know what an asp is? Not a highly dangerous snake, right? Like that's... don't touch an asp. Okay? You you will literally die. You'll die of horrifying poison. Uh, if you know a framework, you can often get a job that has the word

engineer in the title and possibly machine learning. Uh, if you know two frameworks, you might get a job that also has the word "full stack" in the title, but your skill... your skill set needs to go much deeper than frameworks if you're going to have success in your next job.

The one where you get hired because you have three to five years of engineering experience on your resume: senior engineer. Otherwise, you're going to be sitting in a very uncomfortable chair at the 90-day review. You may need to go on a journey from frameworker to programmer

to engineer. Let's look at each of those phases of the journey. I don't like when people do this whole, like, "engineer is different than programmer" business. Okay? Just pick a term and use it: developer, engineer, programmer. I don't... I honestly don't give a rat's ass

about which words you choose. Okay? They are meaningless to me at this point. Oh, it's obtained in my country. Sorry, I don't... I know, that's true for you, but guess what? Canada, nobody cares. Okay? America, nobody

cares that you can't use the word... Oh, I can't use the word "software engineer" because that's illegal? Nobody's building a bridge on C#. Okay? It's not how it works. We don't need some stupid piece of paper that says you

can make bad code because you still rely on Chad Jeopardy, anyways. Okay, that's the worst part; no one cares, anyways. Sorry, I digress. All right, the frameworker: just because you primarily work in a framework or two doesn't mean you're a

frameworker, but you might be. A framework allows a frameworker to build software products in a way similar to how Ikea allows me to build shelving units: beautiful when done, but it's totally not true. Uh, I love the analogy, but at the exact same time, Ikea gives you something that actually

will come out with a final product, whereas most frameworks come out with spaghetti. Okay, it's more like you've been given noodles you need to cook. When the work is done... uh, did I make a shelving unit? Yes. Should I be describing

myself as a shelf engineer? Probably not. What is a frameworker lacking? Programming language knowledge. Frameworkers usually have a fairly rudimentary knowledge of the programming language that the framework is written in. Really well, don't do that; stop it, stop it! What's more, they may not be

aware of the lack of their knowledge because the frameworks are purposely designed to provide abstractions that shield their users from many types of programming. So the frameworker gets a lot of experience in solving a handful of problems with a limited programming toolkit. I think this is a really good

callout in the sense that, like, if you don't know even the fundamentals of how something like tRPC works, or how any of these things work, you should know how these things work even at the most basic levels because, ultimately, at the end of the day, when there is a bug, it's up to

You need to solve it, and you need to figure it out. If you have no clue why your stuff is breaking, don't be at the mercy of trying to get somebody else to solve your problem; you should know something, right? You should know enough depth of knowledge. Frameworkers also

lack the depth of knowledge of software problems. They are using the framework to solve a problem. A framework represents a specific way of implementing the concept of a software product. The low-level implementation is usually abstracted in the framework. Users are provided straightforward ways of

injecting code into the underlying implementation by base classes, decorators, and auto-generated templates. Yep, this makes sense. This makes sense, no matter how crazy React may be; the basics of it are not that insane. SolidJS is much easier to imagine how it works in comparison to

React, but not that crazy. Frameworkers can become adept manipulators of the framework without ever understanding the underlying principles of the framework: frameworks' design patterns, algorithms, CS or ML, asynchronous or distributed programming, and much more. Sometimes, understanding these underlying concepts can offer an

immediate benefit by preventing some misuse of the framework. This is true. I remember when I was getting my master's in machine learning/AI—back when we called it that—and I would write a bunch of MLPs and all that stuff by hand, right?  Radial basis functions,

adaptive neural fuzzy inference systems—this was back in the day before all these cool new concepts. Okay, reinforcement learning was just becoming a big thing, and you know, we had to design those things. So when I see people go, "Oh man, my learning rate was"

Wrong, like I really get that because I had the right, you know, error backpropagation, and my learning rate was a piece of crap. I didn't really understand it until I realized what was going on and what was happening to all the little hidden

layers, you know what I mean? It's it's it's neat to know what happens underneath the hood in some small sense, you know what I mean? Even if it's even if it's now outdated, I have a general concept, you know what I mean?

It's neat, but often one can use the framework adequately with little depth of knowledge. All this deeper knowledge, however, is valuable for one thing: it is massively transferable, not just within the immediate domain of the particular software product, but across all sorts of

programming. What's more, without this depth of knowledge, the framework is not well-equipped to decide whether or not the particular framework choice can fully meet the project requirements. Does any of this matter? I think I mean, I personally think it does. I see more and more a lot of these, uh, right, I see it a

lot: React, uh, you know, just because that's like the most popular front-end one. Just people are React engineers. Stop being a React engineer! Right? At least learn JavaScript, at least the most basics of it. It all becomes so good that you could write the basics of your own

framework and then throw it away and then go use whatever you want to use. Right? Frameworking has a negative effect on the frameworker's career and on the organization they are a part of. The frameworker works in that limbo of writing framework code that is good

enough to merge, but lacking the level of competency that will pass long-term maintainability and a sensibility test. Not only that, but once you become too married to, or you only know one framework, you do something really stupid. Uh, is it this one? Is it blessed?

Okay, it's not blessed. Uh, what is it called? Is it... dang it! Is it... is it Ink? Ah, it is Ink! It's Ink. See, here's the problem: is that when you have a hammer, and let's just say your hammer is React, and you see a UI,

you may go, 'The only way to write this properly is to use the thing I already know,' right? So Ink provides the same component-based UI building experience that React offers in the browser, but for command-line applications. Now, when I see this, I go, 'Maybe, just maybe,

you might have jumped the shark here. Okay, you might have just accidentally jumped the shark, and now you're just applying this one single way to solve things to everything.' I understand that a TUI is kind of like a GUI, that's going to... you know what I mean?

Anyways, stop solving every problem the one way you know. Uh, anyways, that's my one thing about frameworking: is that people, once they start doing this, they start solving every problem in the same way. Uh, the frameworker works in a

limbo of writing framework code that is good enough to merge, but lacking the level of competency that will pass long-term maintainability and extensibility tests. A lot of immaturely procedural code just gets dumped into the right slots. First off, I love

Procedural code: unfamiliar problems are handled with anti-patterns, and organizational code quality drifts downward.  Declarative is just imperative, baby! Declarative is just paradise... but from a career perspective, the frameworker has a bleak outlook. Coders with the same set of transferable skills

using a framework are being churned out by about 50 new online academies every day. Yep, see, this is—I do think this is a fundamental problem, which is that there is a ton... okay, so the *un*problem is that coding is accessible to anybody.

The problem is that we hate gatekeeping, and maybe just a bit more gatekeeping is good. Like, hey, here are some things you really should know; here are some things you should really try to pursue. Maybe it's not gatekeeping; maybe it's some other thing, some way to help people

understand that what they've learned is not the end; it is the most initial seedling of what you need to do. Stop looking at learning as a six-month, one-year, two-year, four-year exercise, but as a 20-year, 30-year exercise.

And if a framework eventually lands a dream job where they get to do more interesting projects, they might end up—might experience a rude awakening when their knowledge gaps become evident. Yep. Side note: they might just be made a manager, in which case they'll probably do

incredibly well. Got them. So what if a frameworker wants to be an engineer? I suggest they start becoming programmers. Program... okay, so this is where this distinction—I don't really care—but anyways, I'm going to use the term 'programmer' with a sense that is somewhat

Idiosyncratic to this article's premise: a programmer, or someone who lives in code—and by that vague expression I mean two things: a programmer is reading lots of code; a programmer is writing lots of different sorts of code. Let's take a look at

those in turn. And heads up: I'm going to switch back to the second person here because I believe you deserve that sort of personal touch. Okay, you'll—uh, definitely—let's see a programmer; let's see the programmer is reading lots of code. You'll definitely hear it said

that reading code is one of the best ways to learn to write good code. I think this is really good. It's my favorite. My personal way is not just to read code, but to first build something and then read how someone else does it, because it's like

you get this one chance to be deeply familiar with a topic and see a completely different way you could have thought about it all at the same time, which is really hard to do in almost anything else, but in code it is something you get to do. So solve Advent

of Code Day One in a language you're not that familiar with, and then look at someone else's Advent of Code Day One solution. You'll go, "Wow, what is that? Geez, I didn't even know about that!" Well, that's super cool. Then you'll do it

again, and now you have all this newfound tools, and then the second time you do it you'll see a whole new set of ways you can do things, or just different ways to approach it with the tools you already know about. It's beautiful. It's

So good, it is so darn good. Uh, you'll learn to cover edge cases and handle exceptions like a professional, but there's an even better reason to read lots of code. The best reason to read code is to just become really good at reading code. The ability

to efficiently read and understand new code is probably the most important single skill that an engineer will have.  A programmer is becoming an engineer because the technologies, languages, and libraries that make up the core stack are constantly changing. Plus, reading your own code from six months ago is the same exercise, okay? Even if

you work by yourself, reading the code you wrote three months ago is equal to reading someone else's bad code, right? Well, there's no substitute for being able to understand code by reading it yourself, and that's especially true when moving into a new job somewhere.

Luckily, there's a ton of code out there to be read, and it can be encountered while doing the second thing programmers do: writing lots of different source code. Oh, I have that problem too! Anyone who thinks I don't write bad code should look back on my own code and go, "Why did I

write that?" You're full of it! Everyone does it. One of the ways to break free from...every now and then, do I...I do look back and go, "That's good." One of the ways to break free from the framework or whatever is to write code that's not typically for you. That

doesn't necessarily mean that you're writing a different sort of app. If you're doing machine learning in Python, you could have a side project implementing ML algorithms yourself. Boom! Uh, bonus points if you do it in C++! But of course, it might mean that

You're writing a different sort of app, trying to write a desktop GUI on top of some of the scripts you run every day, just for fun. You make web front ends, try a text-based role-playing game. This is great advice; this is great advice because this is so dang good, right?

This is exactly it: try something different. Expose yourself—not in the illegal way, but in the legal way, the way that everyone enjoys. Okay, not that other way!  The thing to be mindful of is that you don't simply want to switch from one framework to another.

You're trying to learn. You want to be using your programming language at a lower level than you're used to and then creating your own layers of abstraction on top of that. This is great because even just creating your own abstractions and seeing how far you can take it is an

exercise in itself, right? You should be learning about things like I/O and sockets, event loops, buffers, hash generation, and tail recursion. That last one seems a little strange because that's like...

Okay. Uh, and as you add layers of abstraction, you should be learning about things like polymorphism, inheritance, interfaces, state machines, and design patterns. You should be gaining a vocabulary and then immediately never doing inheritance again, except for that one problem we all know, which is really valuable—which is event emitters—and then somehow

that just makes way more sense, and everyone seems to like that one. But I guess you could also provide a property, but then you'll have this whole public property problem, and then every object has to have the same... Doesn't really matter, anyways. So, when do I...

Become an engineer. The limitations of being a programmer: As a programmer, you'll find that you can do things with code that would have been impossible for you as a frameworker, but it's possible to do some remarkable

things and still be a poor engineer. If you think you're a good engineer, you're kidding yourself. Okay, I don't know about this... this article might derail me on that one part, which is I think everyone should look at themselves as being a bad programmer because you'll

always just take an extra step of care. Uh, imagine that you're building your own car from parts, but uh, as you assemble your car, every time you need to attach a moving part to another, instead of using nuts and bolts, you weld them together. You could potentially build a

car that works really well at first, but imagine something breaks and it's the sort of thing that's hard to get to; you really need to remove some other parts in order to get to it. This is probably a better app description.

Honestly, this is an app description of programming. It's more like welding than anything else. Like when you have to undo something that's under a couple of things, like a couple of layers, you just absolutely have to take apart your program. The amount of... it's actually, I actually like this. I

actually like this a lot. I might... I might start using that.  'Welding' was a bad choice; it may be the choice you have to make, though, for programming. Imagine that you want to upgrade one of the parts of your car; it would basically be really nice if that one part would be

popped off and a new one popped on. I'm not saying that, uh, being a programmer in this sense means that you've completely ignored good engineering principles, but the goals of this programming phase are different from those of the engineering phase. If programming has, uh, been more or

less a linear journey of gaining capability in certain skills, becoming an engineer will be a hard, right-angled turn. Okay, to switch metaphors, you could think of, uh, it like language development. As a programmer, you're getting native-speaking fluency with the language that you work in. As an engineer, you'll start

writing academic prose. Okay, at this point, this is where I think we fully disagree, potentially. I—I let the man cook, but I'm feeling like I disagree. So, what is the mysterious shift in priorities that defines the engineer? The engineer plans and writes software that balances stability and change. Stability is

a straightforward concept, and many programmers provide it in their code. Planning code that can change is more elusive. Balancing the two is what makes you an engineer. I don't like this definition, but we'll—we'll finish it off. Stability—the most—most people understand the main

concepts of stability. The first concept is that software should do what it is supposed to do; it shouldn't be buggy; it should be reliable. The second concept is that the way the software is used should not change rapidly and frequently. That's true in two senses: the

interface should be relatively stable over time, and the interface should be consistent across software. Okay, it's not going to—let's see—I'm not going to spend a lot of time on these, but I'll just emphasize that we say, or that when I say interface, I'm referring to that

Broadly, it can mean anything that you've explicitly declared: all the headers and C++ interfaces in Java, C#, etc. It can mean a consistent set of data types and object names that are interacted with, either in state or in

operations, all a Python, Scala, or it could mean the graphical interface your business users experience. Defining a stable interface is incredibly important, not just for the sake of stability itself, but also for the sake of change. Okay, I buy that definition. Okay, I want to get a good

good song on there. We go. The engineer writes software or changes—the engineer writes software in a way that accommodates change. More precisely, the engineer is able to anticipate the way their software will likely need to change and writes accordingly. Okay, so this is where my disagreement probably

goes a little bit harder, coming up here soon. This ability to anticipate the future is definitely an ability that grows over time, but there are several types of changes that are universal enough to mention here. So a big thing for me is that I think

this is an extremely hard skill, in the sense that I think I know why and how software should change, or what it should change, but often what I will do is not write it that way intentionally. The reason is that trying to abstract for use cases

you don't have often results in code that is brittle. Right, like real talk, it often results in code that is brittle. I do not like abstractions, and I often find that the more abstract, the more I plan for a future that may not be—is—I create a future

That is a path to hell, right? It is just awful. And so often, I don't abstract intentionally because I'd rather feel the pain of not abstracting in the specific way that I needed to change it, such that when I write the abstraction,

for the second time, because now I have the two points of change, I can create an abstraction that is good for both and likely good for another one because now I can really—I can make it more broad, more general, or more specific in a way that makes sense.

And I also feel like this is one thing to say that probably doesn't exist in a lot of languages, but since TypeScript is such a Turing-complete type system, I think it also adds a new layer of typing complexity when you use it in the sense that if you use it in too complex

of a way—a way that allows you to be too specific with what you're passing in and how you use it—you can find refactoring and having to now have a new form of abstraction to be even harder, and it makes your refactors even longer.

Uh, Bucks Engineers that assume that every piece of software that I produce has something wrong with it. In order to change/fix the bug, code should be organized for high readability, and you should use logging—love logging. I won't go in depth here. At a minimum, an engineer

knows how to organize code into reusable blocks, whether they are functions or classes, and knows how to loosely couple those blocks of code so that bugs are isolated as much as possible and require a limited number of changes. Absolutely, that's just—that's just seeing—that's just...

Programming enough, right? If you program enough, you will do this automatically eventually, right? When you fix enough bugs, this starts to become second nature. I always tell people, learn how to code and learn how to test your code without using mocks, because there comes a

point where you start realizing how you should layer your code; where you have, like, external, reaching data manipulation, side-effect-producing, and then the middle part becomes excessively easy to test because you've built your code in such a way that is testable, right? And it kind of

changes how you think about it. I don't know, just a personal thought. Use cases and data and behavior. Now, I remember being on call with a team lead who was being—who was completing an MVP targeted for a single client. I asked, "Have you designed this software so that

it can be used for other clients by referencing a configuration file, or would it be required further software development to use this for other clients?" There was a long pause on the call, and that told me everything I needed to know. When the engineer gathers requirements for a project, even an MVP,

they are constantly evaluating the required behaviors to determine if these behaviors are likely to change in a way that can be captured in a data layer. So this, again, you know, I have a really hard time throwing everything into a configuration because you also end up

with the other side, which is that you over-configure your software. I don't necessarily disagree. If you're building an MVP for a single client, should you build it in an abstract sense that can be used with any client, or do you build it for the individual?

I don't know this example or what it was doing, but I'm always a little skeptical. There are a few things I prefer to environment variable configuration over.  An example: Client A emails you their data as Excel files, which get dumped into a shared drive.

Client B has an API; Client C has you connect to FTP to download the CSV files. Ignore the problems this implies in your business tech integration for now. There are three different behaviors here; your software can support all three while depending on config files—one for each client—to identify which

behavior to use. Then, when Client C finally gets an API, you don't have to do software development; you just replace the FTP information in their config file with the API information. Well, maybe you store it in a database; maybe you have

OAuth login, that you want to do something different. I'm not always convinced configuration is great. I don't know what the deal is; I'm just saying that always just going straight for a JSON file might not be the right approach. I don't

know. All this is possible because you, the engineer, knew from the start of development that importing Excel files from a shared drive was a behavior that was likely to change. You planned your software to deal with data importing via abstractions rather than hard-coding a load client from a shared drive.

Yeah, okay, that's fair. This is again the thing where—this is kind of what I was talking about earlier—you have the loading, the retrieving, the getting of data; the manipulating of data; the output of what happened; the side effect; the display.

Like, it's just accidental; it just happens right here. It's just this; it just happens; you don't even have to think about it; it just happens. Also, yes, getting data from Google Drive is a bad plan. You laugh, but things I have seen... yeah, extensions in some scenarios...

The use cases change significantly beyond what you were either expecting or beyond what you're willing to support. Continuing our example case, maybe you don't want to support data loaders from blob storage from every different cloud provider. Naturally, if you've clearly defined what interface for loading data...

you don't have to. Downstream developers can still use your software to import data from S3 by writing code that implements the interface. Yep, good plug-in support. I mean, this is just more like—again, I think this distinction between engineering and programming...

goes away if you just go—it's experience, right? Experience says, 'Make plugins.' You write it once, dumb; you write it twice, thinking about plugins. That's all it is to me. So, as long as you left the opportunity open for them...

Be An Engineer, Not A Frameworker | Prime Reacts

This is a place for all the things that are awesome on stream. 

ThePrimeTime

The article advocates for self-improvement in software development, emphasizing the importance of engineering principles over framework-specific knowledge.

The author criticizes the trend of developers identifying themselves by frameworks (e.g., 'React developer') rather than as software engineers.

The author encourages learning how software works at a fundamental level and recommends using HTMX.

Frameworks are acknowledged as useful tools, but the focus is on understanding underlying principles.

Examples are given of how frameworks assist in various development areas (web apps, machine learning, etc.).

Framework knowledge alone is insufficient for long-term career success; deeper engineering skills are crucial.

The author outlines three phases: frameworker, programmer, and engineer.

The author dismisses the importance of semantic distinctions between 'developer,' 'engineer,' and 'programmer.'

The frameworker is compared to someone assembling Ikea furniture—functional but lacking deeper understanding.

Frameworkers often lack in-depth programming language knowledge and awareness of their own knowledge gaps.

The importance of understanding fundamental concepts like tRPC and how software works at a basic level is stressed.

Frameworkers may manipulate frameworks without understanding underlying principles like design patterns and algorithms.

Negative Effects of Frameworking and the Path to Programming

The author emphasizes the negative impact of solely focusing on frameworks on career progression and code quality.

Frameworkers may produce code that is merely 'good enough' but lacks long-term maintainability.

The 'hammer' analogy illustrates the tendency to apply a single solution (framework) to all problems.

The overabundance of online coding academies contributes to a market saturated with framework-focused developers.

The author suggests a need for more gatekeeping or guidance in software development education.

Becoming a Programmer: Reading and Writing Code

The author defines 'programmer' as someone who reads and writes diverse types of code.

Reading code is highlighted as a crucial skill for learning to write good code.

The author suggests solving coding challenges and comparing solutions to broaden understanding.

Reading one's own older code is compared to reading someone else's code as a learning exercise.

Writing code outside one's comfort zone (e.g., different languages, app types) is encouraged.

The importance of learning lower-level programming concepts and building abstractions is stressed.

From Programmer to Engineer: Balancing Stability and Change

The author explains that even proficient programmers can be poor engineers.

The 'welding' analogy describes the potential pitfalls of inflexible code that is difficult to modify.

The transition from programmer to engineer is described as a significant shift in priorities and approach.

The engineer's focus shifts to balancing stability and the ability to accommodate change.

Concepts of stability are discussed, including reliable functionality and a stable user interface.

The ability to anticipate future changes in software is highlighted as a key engineering skill.

Code organization for readability and the use of logging are mentioned as important for bug fixing and maintenance.

The importance of designing software to accommodate future changes and different use cases is discussed.

An example illustrates how to design software to handle various data input methods (Excel files, APIs, FTP).

The benefits of designing for extensibility and plugin support are emphasized.

The author advises against overusing inheritance and suggests using interfaces instead.