We like working with the latest and greatest. And who can blame us? A very good developer experience is created as more and more companies and tech backers are investing in these aspects. And then there's another hidden perk: we can also brag about the awesome tech we use at work to our friends that are working in other places with not so great tech.

There's also a lot of out of the box features that saves us a great deal of time and ensures we don't repeat the same mistakes over and over again. Think security, for example - contemporary tech tends to pair with security best practices, some of which are already integrated and we just make use of them, sometimes without even knowing. That's a good thing, isn't it? Sure it is.

Now picture this: you have to work on a relatively small feature using older tech, let's say plain old HTML/CSS/JavaScript (Vanilla) and an older version of PHP.

Well, "have to" might sound improbable for a developer nowadays, you can make your way out of it using various “techniques” available to most of us: talk to HR, convince management that you're not the right person for the job, that the other guy should do it for some <insert very good reason here>, and so on and so forth.

But let's say you accept to do it, still. You say OK, I got this, I'm already capable of doing new tech, older tech is easy-peasy. You run your favorite and awesome code editor that's fully loaded with all kinds of extensions, ones that you might have already forgotten about and start working on getting this behind you.

As you progress, things tend to complicate a bit: some plain old JavaScript and CSS does not behave well in all the browsers you need to support. But you sort it out with some time spent on MDN reading JavaScript documentation, adding some CSS hacks and, obviously, getting help from your fellow developers on StackOverflow.

All good, you're ready to send it to the client for acceptance testing and potentially feedback on how to improve it. Things look good so far.

... and the vulnerability is found by the client. And this is the beginning of the relationship between your employer and the client, so you know that's bad. You realize that you didn't do proper user input sanitation in the PHP code you wrote. How could you miss something like this, what is there left to say to come back from it? Not much, I'd say. You've been in scenarios where you have to back or cover for another dev for his/her mistakes and you did what you could, but now it's about you. Totally different thing.

You fix it during the weekend, test it, talk to the client about the fix, test it again, merge it, the feature looks good now and gets deployed to production. But you just hurt the relationship that you were supposed to help make better. And guess what? Your employer has an on site visit to the client in the following days. Really bad timing indeed.

Management somehow gets another shot with this client, they argue that newer tech helps mitigate some of the common mistakes developers do, like for example mitigating the SQL injection risk. You get the chance to work with what you like and you're good at, let's say ASP.NET Core on the backend and React on the frontend and build a new product from scratch. New chance, this is amazing, right?

But self confidence is at an all time low, you're extremely nervous in every meeting you have with the client. You get (actually need, for obvious reasons) to do weekly demos, they are very intense, to say at least.

Slowly though, you start making good progress, the demos to the client tend to get better as time passes and you get solid pieces of software out the door.

You know .NET Core and EF Core have built in mechanisms to avoid SQL injection, but you test this to make sure. You know React helps mitigate attacks like XSS, etc, but you test again. You need to implement API authorization, you know this is OAuth2.0, but still, you read the documentation very carefully to make sure you don't miss anything. You read a lot about how to store the access token in the browser given the particularities of the product. And then you test, test and test again. You even do a benchmark test between SQL and NoSQL options available in Azure to use as data storage (this could be subject for another post). Your work day is all about coding, no long breaks, no slacking or things like that. But it's very nice and rewarding.

The end result is a well written application that also performs very well. Maybe a bit over engineered here and there, but hey, it was delivered in the time that was agreed so no harm done (it actually proved to be valuable in the long run). The client is very impressed and the relationship has very much improved.

There's talks about starting off on a new product using the tech you recommend, maybe adding an extra developer alongside you. Someone that you know and trust. Everyone's happy. Now you just have to keep it up and build on that, the future looks very promising and indeed it is.

Where do I wanna get with this? Well, it's about mistakes and how to learn and recover from them. There's a saying in Romania “cine nu muncește nu greșește”, meaning “one who doesn't work doesn't make mistakes”. Makes sense, but it's easier said than done. You can make the most out of a mistake by taking the extra mile and making up for it, you can turn into a success story.

Tech wise, don't just say NO when you hear you need to work with older tech, it usually gets your feet on the ground as you need to take care of stuff that you don't think about when using the latest tech. That's a good reminder of how software was & how it evolved and also adds to the “fundamentals” that you need to have to be a good developer.