You have found the only page on the entire internet written by me, about me. I imagine you're here because you've got one of two questions.
Well, I have about a decade of full-stack software development experience. Most of that has been spent at small-to-medium companies, maintaining their five to fifteen-year-old codebases. I believe that the perspective you gain from maintenance programming is valuable, and I'm writing this blog to try to share that perspective.
Well, I have about a decade of full-stack software development experience...
I believe my degree in mathematics helped me build problem-solving skills that would serve me well in most jobs, and especially software-related jobs. The ability to ask the right questions: to trace a bug to its source, to find gaps in the design, to draw out hidden requirements... It's a valuable skill, and I have it.
Sometimes in my career I have taken point on projects where I hold the vision: What should the end result look like, how should it behave, and how should it be implemented? It's a rare gift to be trusted with a project like that - especially with more junior developers looking to me as a mentor. Not all of those projects were successful, but they were all positive experiences thanks to the relationships I formed.
I've been on the other side of that as well. I love working with passionate people, and helping them to reach their goals. It can be very gratifying to work with a good leader who has a clear vision, and to be trusted to handle details along the path to realize that vision.
There's a school of thought that you should be sparing with praise, and I don't subscribe to it. There's nothing better than seeing someone's good work and telling them they did well; they feel good, I feel good, and the product is good too!
On the flip side, it can be very scary to give negative feedback on someone's work. I always appreciate honest feedback that I can use to improve, but that's not universal... What if they are hurt? What if they don't listen? What if it damages our relationship? My approach is to be frank and honest, and trust that they will respond positively - and I have never been disappointed.
For example: recently (at time of writing) I reviewed a pull request that included a class name change, because the responsibilities of that class were expanding and the old name was no longer appropriate. I "approved with comments", saying that the old name and narrower responsibilities sent a clearer signal to maintainers, and perhaps it would be better to carve out a new class for the additional functionality? The developer agreed, reverted the rename, and thanked me for the insight. Our mutual respect and trust made that potentially negative experience into a positive one.
That same week, I reviewed another pull request from the same developer, renaming a function, and changing its class's namespace. This time I agreed - even though I had originally written that code, the new name was more descriptive of its purpose. And the namespace change required a lot of conscientiousness and thought. I was impressed, and I said as much when I approved the code - which the developer was very glad to hear. That interaction was the highlight of my day.
Turning old code into new code that does the same thing is not exactly glamorous work. It takes time and concentration, and you have to manage all kinds of ugly details. Code grows warts and scars over time, and each one has a story about the bug it fixed - and so each one demands respect! And if your refactoring efforts are perfectly successful, no one notices.
No one, that is, except the maintenance developer who comes after you. Hopefully your refactoring will make their job a little easier, because the code is a little clearer, and the next feature is a little easier to write, or the next bug is a little easier to track down. I live for that. One of the biggest long-term goals of my career is that, after I leave a company, someone will get to know me by reading my commit logs - and that they'll be happy I did what I did!
When I think about the successes of my career, the first ones that come to mind are not popular projects or features. They are tools I built for internal users, ranging from tiny javascript calculators to multi-service tracking systems.
One of the great things about writing internal tools is the feedback. Often the user is someone you know, and they can tell you right away what they might change, or what else they might need. Even more gratifying is when the user is someone you didn't know. There's nothing quite like hearing someone say, "I used this tool to find the data - I love this tool!" and knowing that you made that happen.
When I was in school, I was convinced I would have a career as a math teacher. My hat is off, by the way, to anyone working in education. It's a tremendously difficult, tremendously valuable job. It wasn't for me though.
Instead, I teach the people I work with. I'm very good at gathering details and putting them together to present a full picture. I love being able to condense a nitty-gritty system down to a simple diagram with a short presentation - I've got a bit of a reputation for my penchant for pulling up MS Paint. And for those who want to know the details, I'm happy to dive in and help them navigate.
And, if possible, I like to save those presentations, crystallizing them into a writeup on a project wiki or a README file. Good documentation is exceptionally difficult to write, especially for a codebase that's in flux, but I do my best to provide a good outline or guide to the projects I work on.
I spent the first several years of my career maintaining a service that relied very heavily on business logic in T-SQL stored procedures. I don't recommend that approach if you're building a new app today, but I will say it gave me an uncommonly good knowledge of SQL among my peers.
I also have years of experience with web services (SOAP and REST), windows services, and web apps (server-side and single-page apps). The page you're reading right now was written by me for me, built and deployed through SourceHut. You probably shouldn't hire me to design your website, unless you're a fan of brutalism - I do know a fair bit of CSS, but I prefer a minimal style. For a showier example of my frontend skills, check out my fishtank.