I asked a question on Twitter during yesterday's #DevDiscuss about coming across code that you wonder why you wrote it that way.
Liquid error: internal
Now my question for the community, what is a project you've worked on, that years later, you are still proud of?
It could be a small tidy function that does its job perfectly, it could be a super large project where even if the code wasn't great, you still did an amazing job for your level of experience?
Top comments (8)
After just a few months on my second job as a programmer (about 1 1/2 years after starting programming as a profession), I was hired on a new project, where they wanted to speed up the velocity.
I did not fully understand what my project lead meant before, but as soon as I arrived I learned, that there was a BIG VS Solution with more than 200 projects containing all the „C-Languages“: C, C++, C++/CLI and C#.
It took about one hour to build and in case it couldn’t, it was called a build break and everything had to stop until it was fixed.
There were about 25 programmers working on the solution and you might guess, that build breaks weren’t uncommon.
So my job was to split this huge solution, which I called lovingly „The felt“, into several smaller solutions, so that if one breaks, the others could go on.
Easier said than done: I needed an overview. So I used the class graph from VS and could not see anything, because there was one big blob of lines and text. There were 6500 classes in there. More abstraction was needed, so I decided Project Layer would be great.
Unfortunately there was no tooling that could show it to me, so I wrote a small tool myself, including a graph visualization for the result.
Now I saw the interdependencies and was able to talk to the programmers, what was going on the projects.
We split it into 8 separate solutions and after some preparations, we had one week to put it forward during the sprint break. Tuesday to Sunday... and on Sunday at 4pm we had three consecutive successful tests on three different machines starting from green field.
I wrote some tooling around it to let the programmers manipulate their solution and project files, in order to update the dependencies.
Worked like a charm and I am still proud of it.
Sounds crazy! 200 projects is quite a lot! I think the most I've had is about 25 projects but most are fairly thin (eg. one project for models, one project for integration with X product etc).
Awesome work though, solving business problems and making a big mess into something manageable!
It was a lot of work, but I loved it!
And those were a lot of really small projects and even more unit tests for them.
So - yes, it was a big mess. They even managed to build circular references. But it was also a lot of fun... the team was great and even though I was the inexperienced person, I was kind of the team leader, since the project lead just let me do, what I thought was right. And he was very experienced, so whenever I had a question, I could go to him.
For me, there was one project I worked on with my boss. The particular project had a super tight deadline but in the 8 weeks (with a few late nights with dinner at work), we smashed it all out meeting all of the client's requirements.
The project was a database controlled questionnaire where questions asked may changed depending on previous questions asked. Built in .NET, I remember writing some pretty crazy code to have dynamic validation (validation rules were in the DB) work in both the backend and the frontend. There were sections which were a one-to-many of more questions being answered too. There were upload fields, reports and an admin section. This site was built before React/Vue etc and used jQuery/ajax to communicate to the server. Due to the nature of the questions, the database had to be designed certain ways and due to client requirements, the whole site needed to support random spikes of high traffic.
The site had a few firsts for me like progressive use of JS on this scale: when available, the site would use it to do client side validation and nice animation between screens. Without it, the site would do full page submits.
It all worked perfectly and honestly, the client only had one or two issues with it for the years it had been up.
While I might implement it a bit differently now, I am quite proud of the build and the timeframe we built it in.
I work on a desktop support team at a corporation. We do hardware/software support, configuring & deploying equipment, mobile device support, etc. My duties nowadays is more logistics & special configurations along with development for our tools.
Our process for end-users to request a computer was all over the place. Requests were made through a simple web page form that sent an email to a shared mailbox, requests were tracked in that mailbox using different 'status' folders, and equipment was tracked using an Access database which could also provide some standard reports.
We were looking to make this entire process better as it took 1 person all day to deal with this stuff, requests and equipment weren't tied together in one place, old request history could get lost because of Outlook archives (pst files) getting corrupted, and it was difficult to get metrics on any of it.
Having some web development experience, I volunteered to make this happen. It took a few months (not working on it full-time) but we then had a new intranet site with a smallish back-end system written in Classic ASP & VBScript with a SQL database. We used that for a few years but it was getting hard to implement new features with ASP's linear page rendering.
At that point, I took it upon myself to rewrite the entire thing using ASP.net (and learning C# at the same time). When I released this version, it had everything we needed at the time: request workflow, equipment tracking & history, access control, standard & custom report generation. I've been able to upgrade and implement new features into this system many times over the years - things like creating meeting notices for delivery appointments, providing charts for metrics, more intricate reporting, a front-end facelift with Bootstrap, integrating a web service to receive requests from the company's new global form (instead of our user-facing form), and the ability for other support teams in other offices to use the app as a 'self-maintainer' like our team does. I'm currently getting things ready so our UK support team can use it soon.
Long story (made short) I know but it's my big thing that I take care of. This web app has been in service for over 14 years now and it has saved our team & company time and (probably) money because of process improvement along with the reporting features.
Sometimes I do look at the older code in it and wonder why I ever wrote it like that. There's a lot of room for refactoring but not much time to do it. I am still proud of this app and the success it has brought our team in getting everyone else's jobs done faster. Plus I got to learn a lot - from front-end (HTML, CSS, JavaScript) to back-end (C#, SQL, SSIS, IIS).
Great story and great job building it! Sounds like it delivered above and beyond!
I do hope that you do have a chance to refactor different bits in time. Even if there aren't any particular issues, just having something that can be maintained more easily by removing some tech debt is always great.
I was working with some pros on building the OAuth 2.0 authorization grant workflow into the system. To support a specific use case around refresh tokens, I spent my free time building a generic dummy client applicable to all OAuth 2.0 provoders for testing and demo purposes, which helped me understand the workflow even more. It still gets referenced today.
github.com/neverendingqs/oauth2-cl...
Ha it still uses
vars. Everytime I see that, I think "legacy".