"Elegant code is the end" in the real world anyone thinking that way will have a hard time working in so many places. It's a good idea as you get into any workplace to understand at least the basics about companies and their finances, and the 3 drives they have are: generate revenue, reduce costs, reduce risk. You better align your job with one of these 3, and in fact good infra is strongly correlated with reducing risk so I think this whole article could/should have been aligned around that.
Also "product" unfortunately means something different, so also not the best naming... Instead I prefer to ask for clarification of the role reach. In fact just yesterday I was helping a friend who is job-hunting and I had to explain that front-end could mean since he was a bit concerned about "how deep" he needed to know React:
- A person who does a bit of everything, from mockups, design, layout, components, API calls, etc. These roles are normally a jack-of-all-trades type, where it's better to be balanced and know 6/10 of each of these skills instead of focusing only on one. It's characteristic of small/lean teams, SME and people working on internal tooling.
- A person who is an expert in React, working in a larger "front-end team" where there's a separated business person, designer, etc. and you only need to get those designs and build a great (Web)App. Knowing React and Javascript well is quite important. This is characteristic of large teams working on client-facing products.
The type of engineering I enjoy most is the type you only encounter in university and in interview questions: Small, self contained problems, where you can apply a variation of a data structure or an algorithm you already know to find a satisfyingly elegant solution.
The type I enjoy least is where you need to understand a dozen different systems to figure out why the twenty lines you wrote crash 5% more often than baseline, but only on Tuesdays.
I dislike the engineering where somebody thought it was smart to move a hot-loop database call into a self contained class with a static method which connects, queries, then tears down 400 times in a single page load.
I would argue that most of application development using high level frameworks (react, django, node, etc) is not engineering and the word Engineering has been misused by HR departments and the general public.
This is coming from an EE gone web developer who now works as an embedded and hardware engineer. There are trade offs in engineering disciplines that you don’t generally find in highly abstracted web development environments.
+1 to this. Actual engineering just isn't that valuable to most companies. Engineering solves scale and unique problems. But existing solutions that you can purchase or get for free are usually enough for what is needed. The same is actually true in most non software engineering jobs as well. Component plumbing is what people need. Mix and match off the shelf to solve similar problem in a new location. Engineers happen to make good plumbers, but that doesn't make plumbing into engineering. Component plumbing can be very hard, and take more education/experience than an engineering degree, but that doesn't make it engineering.
Although the above may be technically correct, part of me thinks the word engineering might actually be a moving target. It isn't what it used to be, and perhaps the new definition will stick.
It would be nice if you could give examples of the trade offs involved in what you consider "engineering disciplines" that you don't find in "highly abstracted web development environment". Right now your comment is nothing more than a shallow dismissal.
Sorry I didn't mean to be shallow or dismissive. I'll elaborate:
As a application developer you have the luxury of relying on the underlying frameworks to do most of the leg-work for you. As long as you follow basic principals within the framework you can have a reasonable degree of confidence that your application will run and the end product will probably be OK. Things like iOS development are so heavily streamlined that sticking to the docs will mean from a technical perspective the app should be fairly solid.
Of course, it does depend on the application because you could be solving complex problems that are outside of the framework, so I'm not dismissing the engineering definition entirely, but generally speaking I think most developers are developers, not engineers. Developers leverage existing systems and build on-top of them.
Juxtaposing the idea of a web or iOS developer with an electronic engineer that is building a physical product with a microcontroller. The application is written in a "bare-metal" embedded environment which generally only relies on a Hardware Abstraction Layer (which basically just maps memory locations and may provide initialization code for various peripherals) and virtually nothing else. The application will likely need to employ interrupt handlers with safety (Mutex/Semapores etc) that must execute within time restrictions or the system will crash, complex DMA buffering techniques and integration with other hardware using physical layer protocols (SPI, I2C, I2S, 802.11 WIFI, USB, etc).
The transfer protocol chosen will have its own trade-offs, such as speed vs noise and then noise compensation techniques will need to be used such as increasing the spacing between PCB tracks, using ground planes etc, but these then also have trade-offs because your device may have space restrictions.
The list goes on for a while, and every decision that is made eventually enforces a limitation somewhere else in the system. Engineering (in my mind) is about the balancing of these decisions/limitations to ensure the system runs harmoniously and within the defined constraints.
I started out buying into them being different, but then the description of protocol selection, tradeoffs and restrictions sounds very much like developing a distributed software system.
Well, then probably because your experience or knowledge of distributed systems is actually akin to engineering. I'm not debating that it doesn't exist, what I am saying is that generally speaking most application developers, who write a discrete piece of software on an abstracted stack likely aren't making any real engineering decisions.
Not to get into a flame war with Frontend devs, but does this 'akin to engineering' only apply to backend? I know that there are a lot of choices made on the frontend too but don't know enough to see if it has engineering-y constraints in this context.
Similarly, even on a team that does engineer a distributed system, only some of the team members do that sort of activity, the other members follow the set conventions so things work out. Eventually they could work their way up to doing 'real' engineering. I really don't like calling only some things engineering as much as I agree that software development doesn't have the rigor of traditional engineering fields.
> “Product/Infra” maps neatly to the psychology of how engineers pick projects and their motivations for learning to code. Broadly speaking, there are 2 types of engineers2:
> “Product-first” engineers are obsessed with using code to solve a user problem and they see code as just a means to an end.
> “Code-first” engineers are obsessed with the abstractions, architecture, tools and libraries in the code. Elegant code is the end.
> Product-first engineers map to “Product engineering”—building, launching and maintaining features that solve user problems. They often love being in the same room as designers and product managers to learn about users, and they love finding technical opportunities that can improve the product.
So the main line of reasoning is that Frontend vs Backend can paint you in a place where you don't fit. Even combining the Front/Back and Product/Infrastructure axes I still can't describe what I like to do: Platform/API development. That is taking an understanding of the product/business domain, factoring them down, implementing them with a code-first mindset. It isn't exactly elegant code being the end, but having composable interfaces that separate conceptually. Add to that supporting and working with product developers who tend to be frontend/mobile either in-house or third party and sometimes other platform developers.
Early in your career, Frontend/Backend with a particular framework/language will sufficiently filter your options, as you specialize you will tend to be more specific. There are many axes as you specialize, for instance I work with several datastores in great depth. Oddly the frameworks/languages that were good filters hardly matter anymore as the solutions tend to be easily represented in any. I'm more than competent with frontend but my interests and concerns would still be described as backend. I ignore any opportunity described as fullstack.
How about User Experience (UX) and System Experience (SX?)?
UX engineers are creating software for the express purpose of interacting with users, i.e. human beings, and having to deal with all the messiness that entails.
SX engineers are creating software to be used by software. Their focus is on API/SPI design, versioning, flexibility, discoverability and so forth.
> How about User Experience (UX) and System Experience (SX?)?
> UX engineers are creating software for the express purpose of interacting with users, i.e. human beings, and having to deal with all the messiness that entails.
In the latest 5 years the UX are creating software for the express purpose of telemetry and destroying users experience. Every two months there's a major interface redesign. Every two months someone thinks that the users are idiots and need no configuration options while they make grey text on white or black background.
> SX engineers are creating software to be used by software. Their focus is on API/SPI design, versioning, flexibility, discoverability and so forth.
Discoverability is dead. Help is not in fashion anymore and when there is some help available it needs a web browser and an internet connection.
Also "product" unfortunately means something different, so also not the best naming... Instead I prefer to ask for clarification of the role reach. In fact just yesterday I was helping a friend who is job-hunting and I had to explain that front-end could mean since he was a bit concerned about "how deep" he needed to know React:
- A person who does a bit of everything, from mockups, design, layout, components, API calls, etc. These roles are normally a jack-of-all-trades type, where it's better to be balanced and know 6/10 of each of these skills instead of focusing only on one. It's characteristic of small/lean teams, SME and people working on internal tooling.
- A person who is an expert in React, working in a larger "front-end team" where there's a separated business person, designer, etc. and you only need to get those designs and build a great (Web)App. Knowing React and Javascript well is quite important. This is characteristic of large teams working on client-facing products.