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

프레임워크 전문가 대 엔지니어

이 글은 소프트웨어 개발에서 프레임워크 관련 지식보다 엔지니어링 원칙의 중요성을 강조하며 자기 계발의 중요성을 역설합니다.

저자는 개발자가 소프트웨어 엔지니어가 아닌 프레임워크(예: 'React 개발자')로 자신을 식별하는 경향을 비판합니다.

저자는 소프트웨어가 어떻게 작동하는지 기초적인 수준에서 학습할 것을 권장하며 HTMX 사용을 권장합니다.

프레임워크는 유용한 도구로 인정받고 있지만, 기본 원칙을 이해하는 데 중점을 두고 있습니다.

프레임워크가 다양한 개발 영역(웹 앱, 머신 러닝 등)에서 어떻게 도움이 되는지 예시를 들어 설명합니다.

장기적인 커리어 성공을 위해서는 프레임워크 지식만으로는 충분하지 않으며, 심도 있는 엔지니어링 기술이 필수적입니다.

프레임워커에서 엔지니어가 되기까지의 여정

저자는 프레임워크 작성자, 프로그래머, 엔지니어의 세 단계를 설명합니다.

저자는 '개발자', '엔지니어', '프로그래머' 사이의 의미론적 구분의 중요성을 일축합니다.

프레임워크 제작자는 이케아 가구를 조립하는 사람에 비유할 수 있는데, 기능적으로는 뛰어나지만 깊은 이해가 부족합니다.

프레임워크 개발자는 프로그래밍 언어에 대한 심층적인 지식이 부족하고 자신의 지식 격차에 대한 인식이 부족한 경우가 많습니다.

tRPC와 같은 기본 개념과 소프트웨어가 기본 수준에서 작동하는 방식을 이해하는 것이 중요하다는 점을 강조합니다.

프레임워크 개발자는 디자인 패턴이나 알고리즘과 같은 기본 원리를 이해하지 못한 채 프레임워크를 조작할 수 있습니다.

프레임워크의 부정적 영향과 프로그래밍으로 가는 길

저자는 프레임워크에만 집중하는 것이 경력 발전과 코드 품질에 미치는 부정적인 영향을 강조합니다.

프레임워크 개발자는 단순히 '충분히 좋은' 코드를 만들 수 있지만 장기적인 유지 관리성이 부족할 수 있습니다.

'망치' 비유는 모든 문제에 단일 솔루션(프레임워크)을 적용하려는 경향을 잘 보여줍니다.

온라인 코딩 학원이 넘쳐나면서 프레임워크 중심의 개발자가 포화 상태인 시장이 형성되고 있습니다.

저자는 소프트웨어 개발 교육에서 더 많은 게이트키핑 또는 가이드가 필요하다고 제안합니다.

프로그래머 되기: 코드 읽기 및 쓰기

저자는 '프로그래머'를 다양한 유형의 코드를 읽고 쓰는 사람으로 정의합니다.

코드 읽기는 좋은 코드를 작성하는 법을 배우기 위한 중요한 기술로 강조되고 있습니다.

저자는 코딩 문제를 해결하고 솔루션을 비교하여 이해의 폭을 넓힐 것을 제안합니다.

자신의 오래된 코드를 읽는 것은 학습 연습으로 다른 사람의 코드를 읽는 것과 비교됩니다.

익숙한 영역(예: 다른 언어, 앱 유형) 밖에서 코드를 작성하는 것을 권장합니다.

낮은 수준의 프로그래밍 개념을 학습하고 추상화를 구축하는 것이 중요하다는 점을 강조합니다.

프로그래머에서 엔지니어로: 안정성과 변화의 균형

저자는 유능한 프로그래머도 형편없는 엔지니어가 될 수 있다고 설명합니다.

'용접' 비유는 수정하기 어려운 유연하지 않은 코드의 잠재적 함정을 설명합니다.

프로그래머에서 엔지니어로의 전환은 우선순위와 접근 방식에 있어 중요한 변화로 설명됩니다.

엔지니어는 안정성과 변화를 수용하는 능력의 균형을 맞추는 데 초점을 맞춥니다.

안정적인 기능, 안정적인 사용자 인터페이스 등 안정성에 대한 개념이 논의됩니다.

소프트웨어의 미래 변화를 예측하는 능력은 엔지니어링의 핵심 역량으로 강조되고 있습니다.

가독성을 위한 코드 정리와 로깅 사용은 버그 수정 및 유지 관리에 중요한 것으로 언급됩니다.

미래의 변화와 다양한 사용 사례를 수용할 수 있도록 소프트웨어를 설계하는 것의 중요성에 대해 논의합니다.

이 예는 다양한 데이터 입력 방법(Excel 파일, API, FTP)을 처리하도록 소프트웨어를 설계하는 방법을 설명합니다.

확장성 및 플러그인 지원을 위한 설계의 이점을 강조합니다.

저자는 상속을 남용하지 말라고 조언하며 대신 인터페이스를 사용할 것을 제안합니다.