Be an Engineer, Not a Frameworker | Hacker News Reader

Be an Engineer, Not a Frameworker

johndanielraines.medium.com

16 pointsdsego17 comments

I’ve started to understand that some people really want software dev to be mostly about following established processes. Hence intense arguments over frameworks, deifying thought leaders, clamoring for more things to standardize the process of dev, which can be highly chaotic. IMO, this mindset is intellectually stunting, but I think people see it as bestowing certainty.

Good judgement is an uncommon, uncomfortable and expensive thing. The individuals who follow the usual dev process suspects don't want to deal with that so they buy into the snake oil. Every so often it becomes obvious the current snake oil prescriptions aren't working, so the dev process industry pivots to a new approach, usually by taking something that does work (if you have good judgement) and bastardizing it.

I agree, something that's never made sense to me is the fixation on best practices as static rather than situational. I've worked with so many smart people who refuse to entertain any analysis or options in a given situation that don't fall along the lines of what's in fashion in the given era. Despite their situation varying wildly from the conditions under which certain ideas or practices originated. Despite their situation presenting a certain dimension that begs for the solution to be chosen around it.

The field has an obsession with knowledge and an underappreciation of wisdom, judgment, and experience. The fact that "senior" titles are given so freely 2-5 years into the career is a sign that knowledge, which can be crammed and accelerated unlike wisdom, is overvalued as a component of "experience".

Part of this is the obvious desire to use technology that is "resumé compliant" to make getting the next job easier.

The other part is that "wisdom, judgment, and experience" is difficult to scale and often uncomfortable for management. Many/Most want software projects to run like their (imagined, fictional) vision of a civil engineering project or an assembly line where people are perfectly fungible. They don't want some engineer with 30 years of hard experience telling them that the project they promised for 6 months is going to take at least a year, no matter how many devs are hired.

Well, I can’t read the whole article because it is on medium. But I think I understand the gist. For about 24 years I was a full stack developer: installed servers and software and configured them, did DDL and DML work (I wrote many many thousands of sql queries), wrote tens of thousands of lines of server side code, and did front end web development without the use of frameworks like react or Vue.

Then, there was a need for someone to do more integration work and I’d recently come off a project so I was chosen. I’m amazed that anyone that does integration work calls themself a programmer. There is almost no programming involved. 99% of it is just setting up AWS services, hooking them together, using Apache NIFI to process files (which is a drag and drop application - no programming required!), using MFT to transfer files, etc. None of it is custom code. So boring. A monkey who knows how to click buttons and fill in forms could do this work. And yet, they classify people doing this work as senior software engineer III!

I would love to hear what the people who inherited maintenance of your projects might say.

There's another word for boring: stable.

The mark of a good engineer is not the ability to craft sexy, clever, bespoke, ego-boosting applications. It's recognizing there's an appropriate (rare) time to do so.

If you want a challenge, there's always golf or Advent of Code.

> There's another word for boring: stable.

Regarding frameworks that works until your framework of choice stops being supported. Then the fun begins.

The alternative is to create your own framework (named officially so, or not) which is by definition unsupported, unless your org prioritizes it. At which point you're in an identical position. Why not take advantage of the time it _is_ supported?

React/Vue are not a requirement for a maintainable full stack app. Was all code prior to React guaranteed to be spaghetti? Of course not!

Wisdom is knowing when to go custom and when not to. Proclaiming that it is rare may be more an indication of what sector and types of work you do instead of an industry truism.

I don't use react or vue. In fact, these days I don't use any frameworks, personally.

You're absolutely correct the important decision is knowing when it's pertinent, i.e. when it serve organizational goals which of course vary by sector, project, and a dozen or more variables; and that was my point.

It used to be called “integration engineer.” And it sucked then, too.

The most dangerous thing is the myopic view that all programming should be reduced to this drudgery. Not only is it boring as sin, it also doesn’t even work that well sometimes, and resists being understood from first principles.

https://archive.ph/XSPRr

It's rather disingenuous to say that assembling an Ikea shelf and using a framework to build are analogous. The latter is almost always vastly more complex for any product beyond the most simplistic, and requires pulling in skills and techniques which are engineering related.

Be both.

and become an expert in deciding which to be at a given time

Learn good judgement!

  now code can flow.. 
  or it can crash....
  be code, my friend.

Reply on news.ycombinator.com