I spent a few years as the sole maintainer of a moderately complex enterprise app written prettly much entirely in PLSQL. Hundreds of thousands of lines of it. By the time I left a reasonable proportion of that was code I'd added.
A few months after I'd left I got a phone call from the guy who'd taken over the project - he rang specifically to compliment me on the code and how easy it was for him to understand what was going on and how much better that had made his work. Didn't really know how to respond as I've never had that before, but it was nice.
Not blowing my own trumpet, so to speak (although it is something I'm kinda proud of) but to provide a counter data point to your PM's
As a junior dev in my first job I wrote a tiny script to format sql queries for a manual cumbersome process that runs every month. Almost 15 years later that script is still used and it carries my name. There might be one or two people left from that time, basically no one knows who does refer to. My legacy :)
It was pretty cool. The company was founded by MIT folks, so I guess they weren't afraid of mixing C & scripting languages. :-) I was just a junior developer, so I barely understood what was going on. The company tried to build an open source version, but it suffered a lot from second-system effect IMO.
I don't often get to do work as cool as that, but I've really enjoyed pursuing more researchy things in my spare time. Right now I'm working on adding SQL:2011 temporal features to Postgres, so I guess I'm still getting my C fix from somewhere. :-)
In the late 90s I was involved in replacing a software for a financial system for a company that was written in a basic of all languages. It was complex and had almost no documentation. All knowledge of the system was in the head of the programmer of that system and he wasn't happy that his code was being replaced so he was reluctant to help.
The little document that did exist was hopelessly out of date. A lot of business was done on that software
I rewrote a system that runs a midsize company. I added many improvements but one thing that stood out was a view that combines data from many different databases and systems and presents in a easy to understand way. Before users had to switch many times between two interfaces/systems. That page was relatively simple to make but it changed their lives at work.
Edit: I will be honest here, the code in that system ain't pretty as I was still learning ins and outs of the web, databases, and programming in general. Whenever I fix bugs I try to refactor and add more tests.
This resulted in me getting very good compensation in a LCOL area, with extremely chill work environment and complete autonomy.
What really hooked me on programming is when I wrote what later became the Enterprise Knowledge Base of a Fortune 50 company. I was working on their help desk at the time, and the existing knowledge tools sucked, and had HUGE gaps between them.
I wrote something new, and specifically tailored to their process. This was over 10 years ago, and they still use it to this day, and have established a team of people to support it. I'll spare you the feature set (of which I'm quite proud), but the main thing that made it so intrinsic to their process was that it was written FOR their process. It was completely bespoke. It interfaced with their particular phone systems, their calendaring, their ticket tracking system, etc.
It was truly an enterprise-class tool, but for the fact that there weren't any layers of abstraction. The abstraction you usually have to put in to support a variety of databases, or a variety of phone systems, or a variety of calendaring tools because, the market for enterprise customers with MS-SQL + Avaya phone servers + Lotus Domino calendaring is crazy small.
Had it been re-engineered to work for all those systems, then it would truly have sucked. That is, I think the problem with tools like this -- you either conform to the process of the tool, or conform the tool to your process, and it's really hard to get right and stay lean. Maybe impossible.
I wonder how much of that is due to using the current fad tech... my longest running major piece of code (untouched 15 years+), I implemented in PL/pgSQL. Rock solid, well understood technology, isolated from the current hip web framework that is probably calling into the views. Somehow I think the technology choice is a big part of what ultimately made the program a great investment for the business.
On the other hand, I worked on a multi-million line codebase that was deeply joined to oracle’s db, with a team who all really wanted to move away from it but couldn’t because in the beginning (a decade earlier) the choice had been made to not put in “unnecessary” abstractions.
I have a part-time gig where I maintain accounting software for a former client of mine. It takes up a few months' weekends a year.
I wrote about 60-70% of it when I was working for the owner of the software. It's something where as long as the client's happy, and they get new integrations and updates on time, they could keep using it for a decade longer.
I had almost complete ownership of the architecting of the software. It's broken down into a few microservices (think database, core business logic, reporting, auth, logging etc).
The best thing I did at the time was pushing to use gRPC even though management felt it was too new tech.
The UI is in Angular, pain-free periodic upgrades. I've even rewritten some perf-sensitive code in Rust, and everyone's happy with snappier calculations.
The code hygiene is relatively good.
The only downside's that if someone else were to take over the code, they'd struggle (it's one of those things where I'm wearing many hats). I've been fortunate to be a professional accountant who moved into software engineering, so everything makes sense to me.
Well, to be honest, I have taken over about four pieces of software over the years, and one of them was a one-and-a-half time maintenance job (adding one tiny little feature, later finding a bug that turned out to be not in the application after all).
I was exceedingly lucky, I guess, because except for that hairy SQL view, they were all gems of clarity.
It was good code. Some was using a database that got deprecated within our department. Some had business requirements that change pretty frequently because despite being a large company, we have some moving targets in what we deal with.
I worked for some friends a long time ago doing traffic control plan software (at http://www.invarion.com/). We were a startup, three of us in the office, that's it, so when customers would phone one of us would have to talk them. A lot of the customers were not super technical, and I would have to answer questions about features that I had implemented, or bugs that I couldn't have imagined. It was illuminating, and gave me a new respect for developing software and really considering the end user and their needs and abilities.
Well, let me tell you my story. The first company I worked in was developing and selling a ERP to several middle-sized companies- we had about 30/ 40 clients, with maybe half of them requesting customizations and new procedures to be added on a regular basis. We were just three developers, and the ERP was written in C. Not even a SQL database, the access to the DB was based on cursors. Sounds like a nightmare, right? And yet, that has definitely been the most productive environment I've ever worked in.
The secret was a well tested and never changing base library and hyper-specialized developers but especially no deviation whatsoever from the standards ("can we have that string in blue?" "no, not possible, sorry"), a very controlled environment to run on and strictly defined use cases.
Very much so this. There was a strong request for a better solution for the company's database system and I finagled some off-the-shelf solutions but I knew it wasn't great and there was a lot of clunkiness. The users figured this was as good as it gets just had to deal. I wanted to change that.
The workflow was pretty unique and there wasn't much out there that could tackle it in the right manner with price constraints in mind. I set off to rebuild something from the ground-up but tailored exactly to what the users wanted (I kept track of all the complaints of previous solutions). Because this is specific to the company, I was able to make many of the routine tasks automated and reduce time users needed to spend with the tools. Now they actually enjoy when they do! There is no gimmicky extra stuff, it's just software that solves their day-to-day problems. The application I built is super boring, nothing groundbreaking or inventive, but it works.
Seeing it run smoothly in production and having people enjoy the UI/get to spend more time on other things has been quite gratifying.
At work (enterprise stuff) we've grown tired of duplicating 1000's lines of boring CRUD stuff and turned to code generation. Which is so much better.
The workflow now is:
- think really hard for 10 minutes about the business problem,
- describe it into our meta language (typed structs, UML-like, really simple),
- instantly click'n'build a whole set of API endpoints down to SQL create/alter/drop statements, along with full up to date documentation,
- get excited to be able to deliver so much stuff to customer in no time,
- aaand finally receive a requirement update ('the last one I promise') and send I-love-you letters back in time to our old-selves for such a nice malleable framework (which I dubbed The Platform).
The first professional experience that I got in software development involved maintaining a rickety old Access database for the service department I was in. I added a bunch of stuff to it and learned quite a lot. It's not very sexy at all but it did get me noticed.
I'm a developer working on enterprise-level software that's been around 18 years. Talk about legacy code! It's gone from a C++ Windows Desktop/Server app, to ASP, to C#/ASP.NET, to now a SAAS C#/ASP.NET/WCF system.
Not technically a programming gig, but I accidentally wrote the Enterprise knowledge base for a Fortune 50 company while I as working overnight as a help desk technician.
It was a good system, that later fared very well against other COTS packages from vendors like Microsoft, CA, Oracle, etc.
As for how much I knew, the answer is VERY little. I wrote the app to teach myself programming, and the majority of it was in PHP & Perl (because those were the best documented languages at the time) -- and the system ran on RedHat with MySQL, on a spare desktop computer that previously belonged to the other night shift guy that had been fired.
Eventually, all of IT adopted using the program, and I ended up on the team developing new features and performing maintenance of it, while integrating it with other core products within the company, like the incident tracking system.
I spent a couple of years not that long ago basically wrapping a proper production system around a low code system because it had grown so complex by the time I joined that trying to just do a rewrite was not feasible in a reasonable amount of time given our small team. Instead we built two-way sync of the data and built new functionality in a proper system and gradually replaced function by function when we could justify the time cost.
A few months after I'd left I got a phone call from the guy who'd taken over the project - he rang specifically to compliment me on the code and how easy it was for him to understand what was going on and how much better that had made his work. Didn't really know how to respond as I've never had that before, but it was nice.
Not blowing my own trumpet, so to speak (although it is something I'm kinda proud of) but to provide a counter data point to your PM's
reply