[jefflombardjr]

Really great read. Long but worth it.

This is a good critique of low-code/no-code in general. The root problem I see of "Unfortunately, when we frame the problem space that way, we have allowed our tools to think for us." is that in reality there are just not enough qualified software engineers out there.

[keyle]

I got bounced off a front-end job once, for not being good enough at React.

Mind you I've been building SPA's since they weren't "a thing" and today I mostly use Vue.

But for that role, they didn't like my lack of .env variables in the front-end (such as for things that end up in the HTML), after a 3 hours coding test, and a couple of minor React-y tid bits they couldn't even clarify. Basically, not "idiomatic".

Meanwhile, none of them could tell me how React actually works, beyond throwing jargon vomit. They couldn't write a web application without React. The recruiter, which we had to go through, basically had no empathy and saw me as a failed resume. I felt pretty helpless, even though I've said many times to both parties that I wasn't a "React developer".

That is the sad state of affairs today; and I'm finding it's not just in the front-end, where you could argue that you need sanity on this pile of rubbles. It's also in the backend, especially on the auto-magic "DevOps!"

[sdevonoes]

> Meanwhile, none of them could tell me how React actually works, beyond throwing jargon vomit. They couldn't write a web application without React. The recruiter, which we had to go through, basically had no empathy and saw me as a failed resume. I felt pretty helpless, even though I've said many times to both parties that I wasn't a "React developer".

But they don't make money by knowing "how React works". They make money by "writing good-enough React code that pushes features to production". I think get you, and in some sense I feel identified with you, it's just that the industry has shifted from "let's care about our craft" to "let's write good-enough code to make more money"... makes me sad, but hey, it's business I suppose.

I couldn't care less that a candidate knows what "React hooks" are (that's probably gonna be outdated in 1 or 2 years). I care if they know how to write modular code. Management doesn't have the same opinion, though: employees usually work for 1 to 2 years at the same company... so knowing what "React hooks" are now, matters for them.

[88913527]

I don't think React hooks will be outdated in 1-2 years. Between Svelte and Vue I don't see a path for a formidable challenger. You get the complete ecosystem around it. There's tools like Stencil, and I like those tools, but giving people whole-cloth access to make anything, with no 'base' design system, tends to lead to the creation of inaccessible UIs. And it's quite simple to introduce a11y issues. The front end stack isn't moving at the speed it did in the early 2010's, of which I am personally appreciative of.

[int0x2e]

I agree. I think the next big shift will be a fairly big one, not an incremental step. Personally, my money is on Phoenix LiveView - the syntax and concepts aren't super familiar, but the benefits of no longer having to build a lot of your logic multiple times and the ease of scaling this platform are extremely attractive.

[qxmat]

I've worked with people of varying skill-levels but personally gravitate towards those who can code idiomatically. For me it's important I write idiomatic code and follow the language/framework/api guidelines to the letter so I don't become a maintenance burden to my team.

In the fast-paced world of frontend dev, the last thing I want to do is revisit "complete" work, be it a lack of env parametrisation or something bigger. We make assumptions based on idiomatic implementation - failing to conform means work-items can slip ("This story will slip into the next sprint because the I had to convert the callback into an idiomatic action/reducer first").

[travisgriggs]

Which idioms? This week’s? Or last week’s? If I’m at guru level and am capable of evolving to whatever next week’s idiom is, can we code together then?

I agree with you in general. But I do find that this litmus test sets up a moving target in some of today’s more trendy/culty language ecosystems.

[nicoburns]

I think it depends: not using specifically env variables for configuration should let be a big deal. But hard coding values rather than using some sort of configuration file is bad practice and could cause issues on a team.

[ViViDboarder]

This is fair, but silly then to interview someone who “doesn’t know React” if you’re not willing to teach the framework. Frameworks and languages are easy to learn, idioms and all. If a candidate is knowledgeable and can write idiomatic Vue or something similar, why would you think they won’t be able to do the same with React?

[quickthrower2]

I think a lot of jobs are really wanting contractors but paying job dollars.

With contractors it matters if they can code React fast today, not be up to speed in 6 weeks time

[gitfan86]

I have been in a similar boat. I was spending a bunch of time avoiding extra API calls and extra renders in React and the team I was working with didn't seem to understand that there were potential performance issues around that. They said "just use memo"

On the other hand I think it is a natural progression. 30 years ago experienced engineers would look at young people who didn't know how to fix a PCB or read bytecode and think it was a shame. If everyone had to get a computer engineering degree and work at several different roles before they could even build a UI, that would be bad for productivity.

[debaserab2]

It does make you wonder what is going to get missed though, doesn't it? Each generation gets to work on a level of abstraction higher than the one before it.

I think about that often when I think about all the things I don't understand about hardware and EE.

[gitfan86]

I did computer engineering in school 20 years ago, and have always enjoyed understanding technology. So I know what is happening from the gate in the cpu all the way up to the pixel in the monitor. The downside is that I'm spread pretty thin. I can't pass leetcode exams in the 30 minutes of allotted time, ops people can't understand why I don't use containers, and my knowledge is probably useless in making a modern CPU.

[lowercased]

At some point, you may have to look beyond traditional employment situations to best make use of your technical knowledge and experience. However, it might mean moving to consulting and possibly 'selling' yourself on a more regular/periodic basis.

I have soldered chips to boards .... close to 40 years ago, and plugged enough cards/cables together to last a lifetime. (I really don't like hardware stuff!). I've done basic Z80 and 6502 assembly up to ... web stuff today, and loads in between. I can passably describe the innards of some layer of various SQL engines, have compiled linux kernels and various packages from scratch, configured mail gateways, debugged DNS, setup/managed firewalls and intrusion detection systems, can often diagnose various application performance issues from description of symptoms alone, and can do many other things 'tech' related. (not trying to brag - loads of people here can likely do all of this, and more, and better, than me).

BUT... this set of skills often doesn't fit well within a traditional 'job' role. Finding situations where people can get/extract value from a wide variety of your skills is difficult (but can be rewarding when it's done).

I also can't do leetcode stuff, struggle with some 'point/click' things that others seem to find natural, and it can take me longer to 'produce' compared to others (although, I've often found myself cleaning up after others' projects when they leave).

I hope you have found (or can find) some situations that make the most of your skills, experience and perspectives!

[fragmede]

There are still places that need and are looking for that sort of help! Especially inside smaller cloud companies (Digital Ocean, Linode, etc) (or any company that's got their own datacenters, eg Facebook) where the solution to a problem can't be to use some AWS service. A heavy hitting sysadmin (embrace calling it devops instead) like yourself is necessary to getting stuff off the ground to a proof of concept stage, then to production.

Grinding leetcode is falling out of fashion anyway for many reasons, (but Leetcode will never tell you that), but it's still a skill to practice up on and be able to make it past an easy question without problem. It's not a skill you'll use normally at work, but the secret is no one's good at leetcode shit out of the door. It takes dedicated practice until you can pass it the interviews, just like any new skill.

[gitfan86]

I found that I make the most money investing, mainly via Tesla over the past 8 years. I only have about 1% of the engineering skills and work ethic of Elon, but that has been enough to understand what he is doing and ignore all the people on CNBC with MBAs who don't understand engineering.

[keyle]

This resonates with me.

I'm actually thinking that at some point, no one will be building custom software. Everything will be available off the shelf, as some product, running on some cloud within a few clicks.

So "custom software" developers are a dying breed.

For example, when Jira is down, a Jira "specialist" will tinker and bring it back and look like some guru walking down the mountain of knowledge. Arguably, this person probably wouldn't know anything about SIMD. Yet the SIMD guy is looking for a job, no one cares about that guy. But the "salesforce developers" and "Jira specialist" are permanently employed at very high wages.

[oldsecondhand]

Custom software won't be dead because you can't buy integration off the shelf. And JIRA specialists and similar roles will just eat up more of the potential workforce that could be employed as software developers, so software developers will stay a valuable scarce resource.

[smcl]

I think there are quite a few people like us - I have a different background from you, but I do feel like I'm spread a bit thin and haven't really specialized in anything. The good news for us is that I think it's not the end of the world - it's still possible to deep dive into something and specialize in it, so long as you can find the time :)

[int0x2e]

As another generalist that enjoys occasional (very) deep dives but never gets tied down to one platform/tool/skill/problem set - being a good jack of all trades is it's own special skill, and it is quite rare. Small and medium sized teams really need this sort of person as the mythical "10x" engineer, and in many cases this is a great stepping stone to technical/team leadership, PM roles, and entrepreneurship.

[pjmlp]

Having been coding for 35+ years, I feel you.

[fragmede]

> "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

> -Donald Knuth, 1974

[gitfan86]

Just don't forget about that 3% https://www.datacenterdynamics.com/en/news/report-aws-uncert...

[gherkinnn]

I can’t build a fire in the rain, nor can I skin and prepare an animal. But I can buy a slab of beef and chuck it in a pan.

If we’d all be stuck with the very basics, we’d be nowhere. This is why abstraction and specialisation are important.

[scaryclam]

Thing is, if you needed to make a fire in the rain and skin & prep and animal, you'd have a good chance of at least getting most of the way there as you understand the concepts. The problem here is more equivalent to not even knowing what and animal or fire is, nevermind how to do the tasks at hand.

[gherkinnn]

I would starve. As would most. And if I manage to scavenge some food, I’d die of some triviality within a month because I don’t have medical training.

We’re completely and utterly screwed without antibiotics and electricity and farmers.

And I’m convinced that at every step of our species’ advancement through abstraction and specialisation somebody warned of impending doom.

I don’t see how the same won’t apply to software.

[AtlasBarfed]

if you are that good, then why are you wasting your time with front ends? Go into databases. You're apparently already starting to age out of the young and dumb and works overtime flotsam.

[keyle]

I work at pretty much all levels of the pie, but my passion is with what the user interacts with, which is why I tend to gravitate towards the front-end.

Being "good" has nothing to do with being a back-end programmer, imho. One could even argue that the front-end of today is far more complex than most back-ends!

[etripe]

> Being "good" has nothing to do with being a back-end programmer, imho

That's a tough one. As I see it, a lot of the complexity in frontends is in framework feature bloat, subpar tooling and high tech churn as compared to backends. In a word: immaturity. Frontend doesn't guarantee backcompat like backend technologies do, which is also a large part of the (unnecessary) complexity. Obviously, frontends are additionally subject to the whims of fashion in a way that doesn't apply to backends.

In contrast, backends have mature frameworks that can deal with most concerns, allowing the developer to operate on a higher level and with greater confidence in the basic nuts and bolts. Package management is generally sane, to boot.

How much less complex would frontend be if we weren't trying to cram applications into a document model and instead had built-in support for controls/components, theming, data binding and inter-component events? If JavaScript didn't have so many shortcomings or perhaps even gradual typing?

In my experience, frontend skews young whereas backend skews older. That leads to junior class errors in frontends, such as not understanding the benefit of type annotations in a dynamic language and general cowboy behaviour. Perhaps the latter is also down to the general "move fast and break things" approach in JS land.

My own conclusion is backend developers as a group tend to be better, but that's mainly by virtue of having more experience under the belt, being less impatient and taking a longer view.

[doctor_eval]

I’m a mostly backend dev (I dabble in Vue), but it’s seemed to me for some time that browsers are effectively operating systems. The level of complexity of the JS/HTML/CSS troika is staggering, and the number of APIs in a browser pretty much gives you access to abstractions of the whole machine. It’s nuts!

So I have complete respect for professional front end devs. They are every bit as smart as any other developer I’ve ever met.

And then with all that they make it look good too. Something I’m apparently genetically incapable of!

[the_gipsy]

It is! But you also have to put up with everybody having an opinion on it.

[dimgl]

TL;DR: I think you're seriously misguided.

I think you're missing the point on every subject you touched on and I likely would not hire you either.

For one, most frontend developers now use environment variables to feed in configuration specific data, most notably URLs and feature flags, so that they don't need to do find/replace operations in the final scripts (most notably, minified bundles). It really has nothing to do with HTML, unless you've decided to interpolate values in static HTML pages. The environment variable concept is agnostic of any frontend framework and only requires a build tool of some sort, such as Webpack or Rollup.

On your point about not knowing React... I'm not really sure why you couldn't stick the landing here. If you knew they were a React shop, why not just look into it and build a React app on your own time? It's as simple as doing `npx create-react-app` (or something, I forget the syntax) and building your own React app. If you're such a seasoned frontend developer, surely this would be easy?

On the sad state of affairs: I really think this is another area where you're wrong too. I now know Knockout, Angular.js, Vue, React, and just now looking into Solid.js. I don't know the exact internals of each of these tools, but I can certainly explain to you what a digest cycle is in Angular and what hydration/rehydration means in React SSR. To someone who doesn't know the terminology, this can sound like jargon very easily.

On devops: a couple of years ago I found out about CI/CD, monitoring, and a couple of other concepts, and my workflow completely changed in both professional and personal projects. I now spin up entire infrastructures in AWS in minutes using Terraform. And frontend apps are now incredibly easy. I'm currently working on a Solid.js frontend application on my spare time.

So yeah... maybe you should change your attitude a bit. Based on what you wrote, it sounds like you might be the one that's not on the same wavelength.

[wruza]

Why would one go and s/// in a minified bundle when you have the code? I don’t get it. Is your code read-only? Write-only? You can’t follow imports, can’t lookup a symbol definition?

You sound like the one who wants to hire a guy who already worked for 1-2 years in your department. These minor details at the interview like “in your whiteboarding session you didn’t name a constant like we usually do, wrong!”. Duck-diffing as it is it seems.

[meowtimemania]

I agree with grand parent regarding .env variables. During an interview it shouldn't matter whether a candidate uses a .env file or a shared config javascript object, just as long as the candidate can demonstrate the ability to write maintainable code, and isn't excessively dogmatic about their preferences.

[keyle]

Thanks for the feedback. I hope we never cross path professionally! All the best.

[hinkley]

I’ve hear the way to succeed with SAP is to reorganize your business to match either the default world view or some other cookie cutter variant. Essentially using it no code style.

Otherwise you’re exerting yourself doing “normal” things. That’s not sustainable.

[NikolaNovak]

All ERPs are fundamentally like that.

At the end of the day you are purchasing a COTS product specifically to gain efficiency of industry best practices already coded for you.

If you take a COTS product and then try to rewrite it to fit your "unique" business processes, we'll, that's why half of them fail.

Implementation of erp is incorrectly and disastrously viewed as an IT project. It is first and foremost a business transformation project. A company should be self-aware to say "HR|Accounting|whatever is NOT our core business or competitive advantage; it's not what we are great at. It's not a thing we should be unique in. It's a cost centre and we need to standardize and minimize that cost with help of people and software that were successful with many other companies".

(Source: I've been implementing Peoplesoft, a competing erp,for 20 years for dozens of companies, as a technical resource eventually wise enough to be aware it's fundamentally not a technical endeavour :-)

[kayodelycaon]

This is why my company has custom applications that talk to the ERP for certain departments. Inventory control in the ERP isn’t going to work with reality. The data modeling is good enough but the interface is not.

Rather than train everyone we hire to use horrifically bad and expensive barcode readers, we purchased cheap smart phones, put them in cases, and locked them down to run an app that uses the camera to scan barcodes. Drop a phone? It’s encased in rubber. Run it over with a forklift? Toss them another one from the box and then figure out why this only happens on Tuesday afternoons.

We already need a dev team for other reasons. Adding another decent programmer to create and support internal apps isn’t that expensive in the long run. Plenty of good devs like me who are happy to work remote from the Midwest at less than FAANG rates. :)

[tomnipotent]

> This is why my company has custom applications that talk to the ERP for certain departments.

This is the best approach. Inventory is a great example of something that is both very important to an ERP and needs to be modeled impeccably if you want accurate costs (think license plate numbers tracked back to manufacturing), but at the same time you sure as hell don't want your ERP to be the "system of record" for operational systems.

It was a very humbling experience working with accounting and finance to close the books and update forecasts.

[cafard]

My wife worked for an association that got bit badly by the one true platform bug. They had an excellent publishing platform, with features that were then incompletely implemented in whatever association-management platform it was. I couldn't imagine why a clean, limited interface to the platform couldn't have been implemented at less cost. She was fortunate to be gone before the change was implemented.

[NikolaNovak]

Yup there's a few approaches. These days most ERPs have nice semi-modern interfaces making mix-and-match easier, but honestly over 20 years I've seen industry go through 3-4 long cycles between preferences for single-vendor/stack homogenous solution, or "best of breed" mix (I know, buzzwords all but sometimes handy:). It seems one of those things that goes and comes around....

[r00fus]

This outlook is actually endemic in the ERP implementation space.

The part you're not going to like hearing is that, due to laws/regulations, that "default world view" may be the best way to approach that problem for that given module/area (e.g. how to structure benefits or compensation). "Creativity" in the ERP space is costly.

Also reducing your variation to something that's configurable as opposed to custom codebase means you don't have to do extensive testing whenever a patch or upgrade to the ERP software comes out.

[htrp]

That's almost every ERP system....

You could customize it to match your business, but 90% of the time that would cost more than reorganizing your business.

[tonyedgecombe]

One of my biggest customers was bought by their competitor after a big SAP implementation. The consensus amongst management was that the project weakened them so much they became vulnerable to takeover.

[theshrike79]

Yep, this is the SAP way.

Either you match your business to the SAP Way or your multi-million SAP integration project will fail. There are no other options.

You can theoretically prolong the inevitable by modifying SAP to fit your business model, but then it'll just break and fail during the next update.

[cafard]

Twenty-odd years ago we sat through presentations by Peoplesoft implementation consultants. When I looked through my notes, I found that all of them said, with slight variations in the wording, "you have to do it Peoplesoft's way." I'm sure they were right.

[hef19898]

I have it seen time and again. Organizations and leadership being faced with a problem and jumping directly to tool / software selection and implementation before really having understood the problem itself, the processes and requirements. After selection, directly to implementation. Because, you know, we a re agile and working in sprints. So we can sort out architecture and interfaces as we go. End result, tools force you into the use not understood processes that have nothing to do with your business requirements whatsoever, an architecture that is cobbled together and users that don't understand neither.

Even better if the tools are selected based on previous experience alone.

[gnabgib]

The article isn't finished yet (see the footer)... so it'll be a longer read