The sorry state of the programming world as of the end of 2016 AD

I know that I might bore the general population with this topic, but here it comes – another post on why the past was glorious and the present sucks. Before I start, a necessary clarification: I know that “the young generation of programmers is incredibly talented, inventive, productive” and everyone expects to hear that from me. Reality is somewhat different – and you’ll see below why.

We have the most sophisticated tools ever, in the history of man-kind. In 2017 the tools will be even more sophisticated. 2018 will make no exception – I am sure that I cannot even foresee the tools we’ll have by 2020, so awesome and so advanced. There is a catch though. There are very few tools that create breakthroughs in the way things are designed, created, fixed, improved. Most of them reinvent the wheels that were already spinning.

I look at the trend. People switch from things like Eclipse and Visual Studio to Atom or Visual Studio Code, because they are too complicated. People switch from virtual machines to Docker, and now “containers” is the buzz-word that will keep our heads spinning for the next months. Things still happen in the Cloud, although it is no longer that important to have “Cloud” skills, but, instead, hire a system administrator to do the cloud part. It’s no different from 15 years ago when you hired a new administrator when you had more than 20 new servers you just bought to watch. Reality is that, containers or not, nothing changed.

People do feel the need to simplify things. Therefore, more sophisticated tools are created, tools that can hide the complexity of things. Because, I’m sorry to say it to everyone, software does very complex things today. However, since the tools sophistication cannot allow them to be aimed at your problem alone, the tools tend to solve a million problems you don’t have. The result? Disaster. Today’s programming world. Let’s look at a few of the problems we have.

Frameworks and frameworkitis

It’s easy to bash Javascript for being silly – bashing Javascript is useless, and all the retards in the world will jump at you to explain how wrong you are. At the same time nobody actually uses Javascript; it’s hard to find sites in 2016 that don’t include jQuery, for example. For goodness’ sake, my blog uses jQuery and I have no idea why. This blog used to be an input box where I typed my words and they went online. My site definitely should feel like it is a place where someone types a text and that text appears online. But it includes a Javascript framework that is served at each page load.

Why? Well, it’s simple. Javascript sucks, even Javascript developers agree whenever they load up their favorite framework. It sucks so badly that they completely changed it (in a breaking, incompatible way) with the new standard, a version that sucks less, but is still Javascript at heart, so still terribly unfit for the web-work it does.

What do these frameworks do? Things that shouldn’t be done by a framework, to put things plain and simple. They put order in a language that is disorderly by lack of design. They do that badly, because they make some things impossible, which is why people move from framework to framework to solve particularly pressing issues that nobody cares about or knows how to mitigate because they moved already to the newer, shinier framework. A disease that I call frameworkitis, which affects even the most intelligent web-developers out there.

I do understand the problem. I always dreamed of programming video games, and I always felt uneasy with the programming environment I was working with. The thing that I have always done was to start creating my own framework that will allow me to do amazing things later on, at which point I was getting bored with it and abandoned it.

The same goes with Javascript – everyone finds the development environment unsatisfying, and they add their own framework to use it; however, only the most stubborn manage to push their solution to the whole wide world, making the new, probably bad wrapper the new standard. It keeps on for 6 months to 2-3 years, after which everyone will look at you cross and ask you why do you even use that name? We all use Angular 3.1 now!

Gazillion of useless tools

Ah, did you know that Angular 2 is the latest way to do things? It’s completely incompatible with Angular, so you have to throw your code to the garbage bin, but here it is, Angular 2. And we’ll change the version number every few months so you can’t really count on a stable ground for too long. If you’re working on a stable ground you can only make boring stuff. And we don’t want “boring”.

So we have these tools. They all do what “make” used to do, but we have new names for them. It’s gulp, grunt, grump, gash, vomit, throwup, whatever. You will not use this tool two years from now, because in two years we’ll move from letter g, that will totally be uncool, and we’ll use klamp, kulp, krunt, etc. Which will totally be a totally new and awesome new tech and totally rule the totally completely new world of web development. Because everything is on the web now, even if it doesn’t have to be or shouldn’t.

And it’s not like those tools aren’t needed. You need that, because you must handle things that you cannot verify before running. People laughed at leftpad, but truth be told you cannot really trust a programmer to write code, because that code might only be run on the client’s premises, you are not sure that the programmer didn’t just enter a typo that will break execution at any point of time. So you make the programmer use these tools, these dependencies, and everyone is happy. Except, of course, for the case in which the leftpad function will scan for credit card numbers, but yeah, that will NEVER happen, right? The tools safeguard us!

I understand why the tools are needed, but they are really addressing the real problem. And the real problem is not Javascript, is not, really. The problem is the HTTP + HTML model. It no longer works. And we work around it the wrong way.

Reinventing the wrong wheel

When it comes to the web, everyone looks at the wrong problem. Instead of attacking the real issue, they try to create a friendlier interface for Javascript. Two reasons: it’s faster to solve, and it’s easier to understand – basically, the bike shed problem repeated. However, every framework fails to cover all cases, and developers forget that frameworks are not made (as they should’ve been) with the target application in mind, but nowadays applications are built around those frameworks.

Because, yes, kids, frameworks are built to support a range of your particular applications, they shouldn’t be there to solve all your web problems. You should build your frameworks, not use the public frameworks that cover the same thing. But this is a lie that people like Microsoft used to sell things like .NET – you only need our framework!!! And when you want to do something outside this framework you’ll go back to basis and implement it in C++, and link the code like this and that, but really, you only need our framework!!!

From time to time a new language springs up. A new set of technologies, and they all do the same thing: “we will be the better C, we’ll be your perfect web solution and you’ll only need us”. They fail slowly, with a very large response time. You recognize them by what they do. They make mandatory syntax choices like “amount of whitespace”. I know people appreciate python for the inability to understand code flow because you’re not sure how many spaces a TAB has. So they invest in mandatory formatting tools that you have to use with their mandatory toolset that you have to install in a very particular way to work with only ONE project at a time because who in their right mind could work on two separate projects? Soon enough, they will transform your code editor into Eclipse, with worse integration and less features.

Nobody really spends time to really fix the most important, broken element of the web. The thing that doesn’t work. The HTTP/HTML+CSS/JS/jQuery/YourFavoriteFramework stack (because, yes, a lot of frameworks either use or reimplement jQuery) is badly defined, and needs to re-arrange itself. What is HTTP, what is content, what is presentation layer, what is application layer and how the application layer should manipulate the content and the presentation. Currently, it’s a mess, because nobody agrees to use the technologies at hand properly.

Programmers are overwhelmed (and Stack Overflow makes them mindless)

I have quite a lot of programmer acquaintances and I see them caught in this race. Searching for the best framework, choosing the best technology (Typescript! No, Pure JavaScript!) then obsessively searching for how to fix their own choice over the internet. It’s probably impossible to write a web application without Stack Overflow. And remember that Stack Overflow is not a documentation site, is an index of issues. Basically, every framework writer doesn’t give a damn about documentation, and wait until silly users use it, then let other people find a solution for them.

Stack Overflow is a good intention gone incredibly bad. There is no longer any need to think about a solution. People suggested to me that not using Stack Overflow is a liability for a project, because they invest in something that already exists. The only problem? Not only Stack Overflow doesn’t have all the proper answers, they are offered by people that don’t know your problem and don’t understand your product. Maybe the problem is elsewhere. Maybe you need to analyze a bit more the problem you’re trying to solve, or to learn more about the framework you’re using before using it.

While Stack Overflow solves the technical problem, it doesn’t solve the moral issue. Stack Overflow is like the dude gives you instructions on building a noose when you ask for advice on how not to fall on the floor from a chair. Very helpful and technically sound detail, but perhaps not your intention. However, Stack Overflow, like Javascript, is pushed automatically, as THE SOLUTION. I know places where people are systematically disallowed to think and forced to use Stack Overflow instead. Almost every web-development course starts with “the way people solve problems: they search for them on Stack Overflow”.

Agile is eating the souls of developers

For technical problems there’s always Stack Overflow. For everything else there’s Agile. Your brand of Agile development methodologies has answers, and those answers will make sure that your team will be able to deliver a mediocre product in a financially justified long time.

I was looking at one point of time over articles raving about how Facebook refused to hire the guy that went on to create Whatsapp. “They threw off the window X billion dollars” the articles said, because they really think that 1+1 really makes two. It doesn’t. If whats-his-name1)I really don’t care, I care so little that I even enjoy writing this note here instead of searching on Google his name, or even on my blog for the article I’m referring to would’ve been hired by Facebook he would’ve been one of the tens of thousands of developers that are so brain-dead that they can’t even fix the number of notifications the system sends you for the same event. He wouldn’t have been trepanned, no, but instead he would’ve been integrated in a system that wouldn’t allow a single bit of creativity despite clamoring that it strives for every bit of creativity possible.

Agile is a word one starts to hate quite early unless they go into management. Agile makes all things management related easier while, at the same time, it makes the productive herd predictable. Never more productive, mind you, but predictable, the way communism makes people equal by cutting everyone an arm and a leg. It is said that socialism has been conceived to be the first step towards the ideal, communism. I think that capitalism does it better, with Agile being the name of several methodologies that prepare the move to communism (most IT enterprises operating today as oppressive communist outlets, the differentiator being the amount of oppression coming from the higher tiers).

Programmers will jump on the Agile bandwagon quite fast, especially if they have little to no experience whatsoever. Agile allows two very important things: to never answer for your failures and to eat and justify all the resources that the client can invest into the product. It’s perfect for management, and since failure is imminent in the programming world, programmers will also embrace it happily.

Agile methods, however, make sure that the programmer is not allowed to do programming or think too much about how to design or change a technical solution. Everything must be done fast, with only the next two weeks in mind, and you are not allowed to think about a solution, you must delegate thinking to other people. And you have a chain of people that delegate stuff from one to another in a complete mess in which hopefully nobody will ever take responsibility fully for anything.

Everything, of course, justifiable on the timesheet. And it’s important, because the free time of the programmer is important as well.

Mindfulness and new-age bullshit is eating programmers’ lives

When you’re not doing the agile thing at work your practicing mindfulness, you’re reading about mortality and you’re being pounced with fake news on how vaccines kill or how rednecks hate you and want you to die.

The programmers’ caste is full of intelligent, therefore gullible people. And before you laugh at my phrasing, you have to remember that I know what I’m talking about here. Intelligent overworked people are terribly gullible for a simple reason called “Occam’s razor”.

Programmers’ intelect is overloaded with technical requests and very abstract thought. That makes us make some fast decisions, not the brightest, but locally optimized. We don’t remember much information – IT engineers are prone to having a bad memory for things because they have to change technologies and routines often – after 10-15 years of doing that your memory will fail consistently. Therefore, you tend to “optimize locally” and use the information at hand.

That’s why it’s easy to fool programmers into believing anything that they didn’t work with directly. Sure, you can’t lie to them about things they work with or they can verify easy. But, say, throw them a 40 years study on how eating a certain type of food kills you automatically, and they will not be able to combat that – they will automatically become the best defenders for it, even if it’s flawed and full of false data and their own experience tells otherwise.

So programmers are a gullible lot, and they eat any new-age bullshit that comes around, especially if it’s combined with ideals like “being more productive” or “improving their livelihood”. So you will find technical people deeply involved into sects that combine Agile with Mindfulness for a full bag of horse manure to eat.

This is definitely a personal look at the programming world today – coming from a Romanian developer working in Romania. I am not sure how this applies to India or China or Japan. I’m not sure if this applies to the US, UK, Germany, or France. Perhaps it doesn’t. I am just commenting from my direct experience and from the experience of people I know and of people that they know.

But I want to get back to a thing from my first paragraph. The new generation of developers is amazing and other bla-bla like that. It’s not. They have incredibly powerful tools and they use them badly – they misuse them because they generally don’t understand them. Creativity is seen when they reinvent the wheel because they wanted it red, and when they do the same wheel square again, maybe it will work again – and if it doesn’t it’s an artistic statement or something. The new generation of developers is not better nor worse than those before them, but it’s definitely more numerous. That is a statement I can get behind.

A lazy bum with a higher level explanation: totally works with Agile methodologies!

NOTES   [ + ]

1. I really don’t care, I care so little that I even enjoy writing this note here instead of searching on Google his name, or even on my blog for the article I’m referring to

Comments

The sorry state of the programming world as of the end of 2016 AD — 30 Comments

  1. A simple off-topic mention, though: most amateur game creation tools have gone a long way to simplify things in late years and that’s actually a good thing, mainly since complex creations require much more than a good engine and/or hefty programming. However, that is a very particular case that does not invalidate your premises in any way.

    • Gaming is a particular case that still attracts actual, real talent, and people that don’t really find solutions to their problems on StackOverflow.

  2. If you were to sketch some kind of “design” within your mind on how would you solve differently, let’s say, the HTML-CSS-JS behemoth, were would you start? After so many deconstruction from your article there is desirable to have someting to put in place, isn’t it?

    • An amazing, awesome question, that deserves a lot more than a blog (not a blog post) dedicated to answering it. To put things short:
      1) HTTP should be more than the stateless protocol we have today. AJAX, sessions, other similar stuff done at the wrong level – initially due to lack of resources. But today? I think we can do better at the transport level.
      2) HTML+CSS are a nice pair – HTML5 fixes some things, but still is very unclear – what is style-sheet, what’s HTML? What does the article tag really do? Why have multiple ways of doing the very same thing? Why does the page have to be human-readable? I do understand why the content is useful to be human-readable, but the page description?
      Also, define an unambiguous set of primitives and work with them.
      3) JS – I understand why people use JS – the entry level features are awesome, and you can write code and run it in your browser. Nice. But it’s so easy to write bad JS that it’s almost impossible not to. I understand the appeal of an entry level “kid” language, but I think that webassembly, with a „your language of choice” backend is what a webpage needs for scripting.
      4) DOM – The DOM should be a feature of the browser – things that were implemented in jQuery should be directly available as part of the platform support of the webassembly part – like a platform API. Same goes for events. AJAX, will also go into that platform API, but implemented at HTTP level

      Of course, all these things need energy, a lot of people agreeing on things they never agreed on out of principle. But the browser as a platform, today, is working against choices that don’t make sense in 2016 anymore. and the browsers started showing their limits.

    • Dorin – the question is – how to get everybody to agree upon a common platform for rich client applications that is cross-platform and not proprietary? We had several proprietary technologies that each tried to ovrerome the limitations of HTML+CSS+DOM+.. – Java applets, Flash, Silverlight, and all failed for one reason or another. 🙁 (not necessarily for technical reasons )

    • Neither ever tried to be a full solution for browsing, with all the required openness; they all wanted to be application frameworks in a sub-segment of the browser page.

  3. The immediate answer to the intrinsic question is quite obvious, dude. To keep people busy while doing nothing. Many of today’s uses / purposes aka ‘vision mission BS’, if not most, revolve around ‘solving’ ‘issues’ we shouldn’t be having in the first place. I’m talking about what technology serves for, in general.
    With all of this pure horseshit, be it ‘information’ or a way to store, distribute and display this so-called ‘information’, many people spend the larger part of their intellectual and physical resources simply filtering (or give up in the process). There’s really not much left for really achieving a vision, seeing a true problem and eventually looking for a way to solve it. Stuff is just steadily turning into a hamster wheel, often mixing up cause and effect, to the point it’s really difficult to recognize which end is which – as in, you don’t really know what started it and what’s the point where it’s also powered by mass choices.
    It’s the same as with public transportation and the bus/train/car/share talk. Keeping busy, that’s what it is. At least in Romania. It’s far less costly, at least in the most important resource, which is time, to set up a relatively sane network of mass transportation, but all you ever see is cars. By using them, everything gets built around the concept of people using mostly cars for mundane trips which should not require them and then you hit rock bottom when trying to ‘disconnect’ and go against the tide (or do it your own way, at least).
    Truth is, you used to require 20 GOOD programmers for something that nowadays directly feeds one or two sub-mediocre developers, some testers, a project manager and some fraction of the support crew. Yes, it’s not the needed product, it’s built miserably, but it sort of does whatever it’s supposed to be doing (and then some stuff it isn’t) and keeps people busy.
    And yeah, I suppose it’s a sad time to be a decent programmer with a desire to really do something useful.

  4. I mean, just look at project managers, leads, whatever, who, after a hard days work, pile up for a flashmob defending ‘animal rights’, completely oblivious to the fact that with each of their annual useless gadget purchases, they endorse an industry which turns hundreds of miles of land into unlivable landmasses for all living things, including plants, humans, whatever else. They’re creative, they’re involved, they’re political – the perfect fucking idiots for a shitty time which would gives Kafka a run for his (lack of) dough-nuts 😉

    • You’re one of the few here – what I feel is that IT people, too tired from the daily hassle, don’t have the energy to think outside of work-time.

  5. All these somehow contribute to the bad performance and ridiculous system requirements of most of the new games these days.

  6. I disagree. Good developpers insulate code from the framwork. Bad developpers embrace it. Why would you reimplement your framwork ?

    When one uses, says symfony, he can easily have independant componenents and do the plumbing throug DI.

    The web is undergoing changes. Web assembly is comming. Emscripten permits to run compiled programs in the browser!

    And no, developpers aren’t as good as early ones. My main work is reviewing code. The overall quality goes way down. Most programmers can’t even explain the journey between entry of URL and rendering of the page. I am not even mentioning punny code or other twists. They get the basics wrong!

    As for tooling ? I demonstrated Jetbrains IDE. They should increase overall quality since they give real tile feedback. But guess what? These are purely ignored !

    HTTP stateful ? Are you kidding ? Don’t you realize that you have mutiple nodes AND caching available ? HTTP is designed for a broader spectrum than serving HTML, CSS and JS… It’s basically designed to serve resources. Want to brew coffee ? Use the Tea Pot protocol!

    Something to replace Ajax ? Why ? It works pretty well and benefits of stateless nature of HTTP! Need something more connected ? Use websockets…

    You should definitely upgrade yourself too.

    Start by underatanding why HTTP is stateless, why web assembly, web sockets, transpilers, domain specific languages and hexagonal structure.

    Definitely have a look at Ansible & Puppet too. (Provisionning)

    Finally, try out Jetbrains IDEs, Kotlin & go.

    Then read your post again!

    • I am not sure why you think I’m a dimwit and I have no idea what I’m talking about. Please read my post again, and try to think that I know more than you. Because probably I do.

    • You certainly are a no match ! How can I know it ? I am paid to control work of senior people in financial apps in Gaming.

      That do not only cover code quality (Eg. Can you migrate your app from AngularJS1 to AngularJS2 without touching 90% of your code ?), but also security, user experience and technology intelligence.

      I also assess people (Oh, yes, HR skills too).

      All your griefs are clearly against your case. They show lack of abstraction, lack of knowledge of basic technologies, ignorance of recent (<5 years) technologies.

      Sure you still don’t understand HTTP protocol and why it is stateless. For websocket, you clearly didn’t spoke about them and preffered to say that Ajax is limitted etc.

      Think as you which that an hyperpolyglot expert who control and advise seniors has less knowledge/competence/skills than you.

  7. Pingback: EOY 2016 links – Ad Astra Per Aspera

  8. Pingback: Good old times – F7L8C9

  9. So I was trying to write a website. I did write my own MVC in PHP at the start. It worked well, but it was tedious, for every new functionality I had to reinvent the wheel. In order to get better productivity I’ve started a journey of exploring frameworks and tools.

    I tried using angular1 and it was so messy, poorly documented, poorly designed, etc. I’ve tried to use react, but at that time there was no documentation on it whatsoever. I’ve been told that Laravel is great but I couldn’t understand much from their documentation at that time, funnily enough one of my much less brighter friends had no problems using it.

    Symphony has been such a help because it explained the flow of data inside the framework, what my job is, how DI works, etc. I ended up using Symphony and not liking some of its code and practices either. For example, it has a tool for building forms inside controllers (have a quick look http://symfony.com/doc/current/forms.html#building-the-form ) which is completely counterintuitive (breaks mvc) and extremely unadaptable especially for my task: uploading multiple images and changing the html based on the result. Never used that Symfony functionality. Maybe I’m the one that is crazy and doesn’t understand…

    Still, I think that to this extent frameworks are good. Taking care of tedious tasks that have been done 1000 times before like routing, DI, interpreting parameters in a request can easily be taken care of by a framework and make your work easily adaptable. Switching from Spring to Guice or whatever DI framework shouldn’t really ever be that hard. Using some of the more complex features of Spring can usually still be swapped to something else without having to change too much of your perfectly written, clean business code.

    You say HTML + HTTP are a problem. HTTP is pretty good for working with resources, services, etc. in most cases. I’m not sure what the problem with HTML is, perhaps you can clarify?

    The web browser is sadly used as an universal VM in many projects. It works but it wasn’t built for this (Java was). Angular 1 is imo one of the biggest offenders. The programmers working with it are extremely inefficient and for some reason the companies keep dumping huge amounts of money in making angular projects, it really baffles me. It’s really Java’s fault, for not pushing JavaFX forward at a level where it can compete. C# is a great option if your customer only uses Windows and Swing requires a serious time and manpower investment. Working with Android was a joy, but I haven’t seen anything like it and it only works on Android.

    Anyway, what are you talking about when you say HTTP + HTML is bad? Even with a desktop application, if you need full duplex you go sockets.

  10. Pingback: Resuscitating the dread word ‘Agile’ | Daniel J Scheufler

  11. I can only say that some of your “frustrations”, based on my experience, will not go away. The same thing was said about PC, about its architecture 20+ years ago. And still we use them without much comment. And no only use them but also write specific code for them. It will pass a long time until an ARM (“clean architecture” as supporters say) will dominate in the world of PCs/Macs.

    Now back to HTTP and web technologies, the same thing we got here. But not only we still use HTTP and new “improved” versions of HTML but not much has changed at the core, as you would expect. And it’s not gonna change, at least not in the next 3-4 generations (~100 years). The Internet is full of “why HTML/HTTP is wrong” but ironically written in a HTML page sent via HTTP. And those articles are old.

    I guess this translates to something you’ve already posted which is building a better linux distro. Same thing, it’s not gonna happen, at least lt’s not gonna be useful for more than few people, yourself included.

    I agree about “frameworkitis” but that’s only valid for people thinking they develop software rather than making code only from bricks of lego (red frameworks). These are not software developers.

    I don’t agree about stack overflow. I mean if you know how to ask a question you might get relevant answers, and if you how to read answers, again you might get something useful. There are many eyes there.

    The main issue with developers is the fact that NOBODY writes code anymore. Everybody patches, fixes, adds a new module (smart patching I’d say – which is copy, paste + adaptation). It’s not the frameworks, we had those 25+ years ago; it’s the fact that people write less and less code. And this would be a good thing if everything was already invented, handled, written, but unfortunately it is not.

    And developers, I mean the ones who actually write code and are able to perform that task, are usually suffering from NIH syndrome. They always start doing things all over again, like hand written parsers, lexers, services with old technology because they want to “be in control”.

    So yes, the programming world is in a sorry state. I see it mostly split between these categories:

    non programmers (patches, bug fixers etc)
    NIH syndrome programmers (around 20-30%) – I’d include you here in my opinion
    actual developers (less than 5%)

    • Thank you for your long and insightful comment. I generally agree with your opinion. I do understand why you think I talk from the NIH perspective. Only I’m not. I will give you only one example: do tell me how long are the web frameworks supported, and how long are your projects going to be supported on the long run?

      I would use, for example, the .NET framework, as it’s maintained and improved and supported for 15 years already. I cannot guarantee anything about Angular 1, already abandoned, the starlight of stars. And we’re talking about… how many years? It doesn’t mean I want to write parsers and lexers, I’m not an idiot, the client doesn’t pay me to do that unless they do, but seriously, I cannot sell them a solution that will become unmaintainable in 2-3 years.

      Also, I have worked on long term projects as well – projects that are meant to be maintained for 10 or more years. Your point is moot. I would love to have the code for some of the custom frameworks I used on those projects, because I would definitely fix some things there.

      Doing frameworks is hard. The JS crowd loses interest as soon as the first difficulty arises, and they work on weak foundations. About your „ironically” HTTP and HTML thing, be informed that the HTTP and HTML stack was developed by communicating via gopher. You’re in a big error here, but I guess you’re living in the „actual developers camp”, it’s too busy out there to think.

    • Dorin, I would compare Angular not with .Net Framework – it’s more similar with the plethora of UI libraries that we used during the years: WinForms, WPF, Silverlight, and on top of them DevExpress, Telerik, MVVM, Caliburn or Prism and many more… and now Xamarin and Xamarin Forms.. All are still around, but the first three went out-of-fashion 🙂 – today in JS world we see the same phenomenon, just in much faster succession..
      The problem is the JS universe lacks a ‘base’ / common library like .Net Framework, even if some would say that this is a good thing.

    • WinForms and WPF are still supported – even Silverlight is still supported, it just doesn’t integrate anymore with other things.

      And yes, what I’m saying is that the JS lacks the solid foundation it needs. But here I am, being called bad developer for naming things the way I see them.

    • Even Crockford in it’s famous book (JS The Good Parts) recognised that some bad design choices in the language must be covered with additional library code.. Newer ES versions tried to compensate this, but..

    • Just to mention: I think I find myself swinging in the last two categories, sometimes I need to reinvent the wheel though I wouldn’t want that but hey I’m not doing some rocket science or advanced research.

      But I’m glad that my point was understood.

      When it comes to long term support of projects that’s highly debatable. Some projects will need support for a long time (read: full time programmers on them), but others are just projects that need to be delivered (read: outsourcing) and most likely offer limited support after a certain period (usually max 2-3 years). I’m not saying that those projects will die after 2-3 years, I’m just saying that YOU, as a dev, won’t be doing that maintenance which is important in my opinion.

      WebApps: You wrote them in angular, react whatever. It doesn’t matter, the backend will most likely stay the same. The tests will still work but the interface will change. It’s not a monumental task in my opinion. I know people porting to web a command prompt interface input just to go on with what existed before (read: less training, no new people needed to be hired). I don’t find switching from an UI framework to another that hard, unless it was written by those 70%+ that know only copy paste from various sites without even bothering to investigate. A decent (no even fully correct) MVC should be enough for these cases. Usually the most important part of a webapp is the design which shouldn’t be done by any coder but by a professional designer.

      And in general this is the way stuff works: Usually you start with a core of people that know what they do, they draw the architecture. After the architecture is in place and some things are implemented the stuff goes to “cheap land developers” (include .ro here) who will base their work on the original thinking not actually knowing all the background behind some decisions. Frameworks? I think this is a little too far. We’ll always have programmers swearing at the architectural decisions (idiot, stupid, too old etc) but that’s pointless since rewriting is most of the times out of the question. Rewriting happens mostly when frameworks begin to have clear limitations that become an obstacle on medium-term for the project. And since rewriting happens seldom I think frameworks are ok. At least at decision level, because at programmer level everything needs to be updated, rewritten etc.

      PS: I just said I’d include you in the NIH category, but I really don’t know much about you except that linux post representing your opinion (which I respect).

Comentariul tău