This post gets you up to the point where I started programming professionally. The TLDR is that I took a long time to finish school and worked in between. I developed some web apps, but didn't like programming. I was more interested in ops and networking. But my first job after graduating college turned into full-time programming after about a year.
I got to do interesting work in my first full-time programming job. I built a system to collect and validate records from all the two-year colleges in the state, so the state could meet reporting requirements. The fun part was the back-end service to pull and process those records and run validations. It was multi-threaded so it would process multiple kinds of data at the same time. But some of the data was dependent on others. So, I essentially got to write a multi-threaded, dependency-aware queue system. It ran on a schedule, but a college could also trigger the data to be re-imported ad-hoc. I also did the web UI with logins for colleges and state. At some point I found out I was drastically underpaid, but I was having a blast and learning a lot so I stayed anyway.
Eventually, it worked well enough that they stopped letting me play with the back-end and the only work I had was writing reports. This is misery for my builder personality, but before I figured that out I did a lot of yak shaving and exploring other techs to quell the boredom. I was the first full-time dev there, but eventually more were hired for other projects. So I did a few lunch n' learn sessions on techs that we weren't familiar with. I researched a lot of design principles too. (Though inexperience blinded me to the value of some of the good stuff initially, or sidetracked me into wasting time on niche tactics.) Eventually, I figured out the source of misery. I asked to be moved to another project, but apparently all the programming work they had available was reports and more reports.
About midway through my 6 years there, I had the inkling that I would like to get more deeply into software architecture. By the time I left, my resume cover statement was "Turning the corner from coder to architect." I knew I wasn't there yet, but I had a strong interest in that direction.
My next job was as a lead in modernizing a business-critical internal legacy app. It was my first time working in a team of 4 and using scrum, and I was leading the modernization effort. So my boss took a risk on me, but she said she was glad to have done so. Turns out I'm not too bad in a team (a pleasant discovery for me as well, being an introvert), and I ended up incrementally rewriting the majority of the system in under 2 years. The other dev mostly specialized in other things, but she waded in there too at times. I got to try some design and architecture bits and bobs along the way. And I never stopped pressing forward on learning architecture and design, often in my spare time.
I was also very fortunate to be co-located with the UX department. Not only were they fun people, but I really latched onto user experience as an important feature of any application.
Eventually the rewrite was done "enough" and the business wanted to switch focus on a deep integration effort with another product. I really liked my team, and I was not looking for another job. Nonetheless, I was asked to come back to a place I had previously worked in college. It was to help modernize their legacy system -- a monster which I had helped create years ago. Only this time I would have carte blanche on technology, architecture, whatever I wanted. I declined the offer at least once. But ultimately I made the really tough decision to leave, after 2 years and change. And initially the plan was to leave for a few years to help out that company and then go back to my previous company. (Believe me, I asked to make sure that was a thing.) That brings us to where I work now.
When I first came back on board 4 years ago, the plan was to do a big bang rewrite of the system. In the back of my mind I knew it was a bad idea, but there was general agreement that it was the best plan. It was also a siren song to start the architecture with a clean slate. However, since I had been gone the system had become pretty sprawling with a lot of apps integrated through a database. As I developed the new system, it became harder and harder to understand how we could possibly migrate to it from what we had. Eventually, the executives got tired of not getting business value from my expensive salary, and directed me to fix some really painful issues in the legacy app for a while. It was after that point, my manager and I agreed to abandon the rewrite. Instead we started implementing the good things we learned from the rewrite into the existing system. We made a lot of positive changes to ease pain for various users. (And we still have a lot of work to do, but we can at least see a path forward.)
The next series of events is pretty fascinating. I was really yearning to get more architecture experience. To recap: I was only supposed to be here a limited time. The original reason I came fell by the wayside. So, I figured they would let me go to hire a less expensive person to keep working on the system. I even told the director that at my next job I was ready to lead a team as architect. Not long after, several customers independently began asking us to develop a new product that wasn't directly related to our core business. My (hindsightedly stupid) advice to the director was "No, we aren't a software dev shop." But they persisted and we agreed. I picked the tools we used, and designed the multi-tenant architecture for the cloud. I hired 2 devs with no experience and trained them (mostly giving them time to explore). We lost one dev to greener pastures after a couple of months, but made our first MVP release in 6 months. Almost a year and a half from the start, we have a pretty decent offering, and we are talking about making it publicly available (so far we have gotten business through person-to-person pitches to industry contacts, and word of mouth). I'm getting around to implementing arch changes that I had planned but lacked time to do initially -- especially to enable scaling the infrastructure and our team. Other products are already in the works... looks like we might turn into a dev shop yet, and I might never leave.
We've used some of the same tooling and infrastructure from that to rewrite or add to some of our internal apps as well. Making them worlds better in function, stability, and appearance. These changes have been a big hit with our users and customers.
Of course, that's the sunshine and rainbow highlights. There's also the overwhelming stress of being responsible for the success or failure of the technical aspects. The nights and weekends reanalyzing your decisions for holes or researching for that next step or that missing piece you haven't nailed down yet. Sometimes I want to quit and go dig ditches for a living. :) And I by no means consider myself a seasoned architect. Although I studied the research and theories surrounding it for years, I've only made a beginning in the practical application.
wait i already do this - "The nights and weekends reanalyzing your decisions for holes or researching for that next step or that missing piece you haven't nailed down yet" 😬 heh.
thanks so much for sharing, this is a very colorful path and had some unexpected pieces in it. i love that your company worked its way to abandoning the rewrite, and incorporated what you had learned into improving what you had. rewrites have their place, but replacing sprawling legacy apps is a lot tougher than people give it credit for!
I'm not sure about your situation. But for me, I never got the opportunity to be a "junior" developer and have someone else be ultimately responsible. There was no one else available but me in most places I worked. So, I also felt this way throughout my career... that if I didn't get it working, the effort would fail. It's not so bad as a solo developer on a single app here and there, but I find the stress much greater when my decisions play a part in company strategy and people's careers. To be honest, I find myself in paralysis sometimes... endlessly researching to get a picture of how every corner of the architecture works together before I even take a step. In particular, I try to thought-experiment each detail to uncover the obvious trade-offs as early as possible. But time being finite, I often have to move forward with my best guess. I need to rediscover the playful attitude with which I approached this stuff earlier in my career to make it more fun. Although it remains intensely satisfying to have created something that works well and meets a need.
I believe that large spaghetti systems make it nearly impossible to justify a big bang rewrite. There is just no way to account for all the side effects that are baked into the system. (e.g. App A depends on App B setting some data, but only sometimes.) The new system will miss a lot of edge cases because they look like accidents and noise. Therefore the cost of creating the new system also extends to adding missed edge cases for a while after it is first deployed. And that only gets you back where you were before the rewrite, with maybe a few new things added. Plus your users are angry with so much change at once. The right way is to carve off pieces of the system. That gives you a chance to dig into that area and talk to your users. Then you can not only modernize things, but you can also add value while you do it, and let users adjust in small increments. That piece gets deployed separately and its responsibility removed from the legacy system. Rinse and repeat. Smaller is easier to throw away and rewrite.
this is similar to my experience so far. at my last job i was a team of one. i had people i could pester with questions, but they were on a different team (read: under a different cost-center in the company) so questions were definitely not encouraged.
at my current job, i'm largely independent again (although my team is fantastic!). i'd love to be in a situation with more expected collaboration. so maybe these experiences can actually be good things :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This post gets you up to the point where I started programming professionally. The TLDR is that I took a long time to finish school and worked in between. I developed some web apps, but didn't like programming. I was more interested in ops and networking. But my first job after graduating college turned into full-time programming after about a year.
I got to do interesting work in my first full-time programming job. I built a system to collect and validate records from all the two-year colleges in the state, so the state could meet reporting requirements. The fun part was the back-end service to pull and process those records and run validations. It was multi-threaded so it would process multiple kinds of data at the same time. But some of the data was dependent on others. So, I essentially got to write a multi-threaded, dependency-aware queue system. It ran on a schedule, but a college could also trigger the data to be re-imported ad-hoc. I also did the web UI with logins for colleges and state. At some point I found out I was drastically underpaid, but I was having a blast and learning a lot so I stayed anyway.
Eventually, it worked well enough that they stopped letting me play with the back-end and the only work I had was writing reports. This is misery for my builder personality, but before I figured that out I did a lot of yak shaving and exploring other techs to quell the boredom. I was the first full-time dev there, but eventually more were hired for other projects. So I did a few lunch n' learn sessions on techs that we weren't familiar with. I researched a lot of design principles too. (Though inexperience blinded me to the value of some of the good stuff initially, or sidetracked me into wasting time on niche tactics.) Eventually, I figured out the source of misery. I asked to be moved to another project, but apparently all the programming work they had available was reports and more reports.
About midway through my 6 years there, I had the inkling that I would like to get more deeply into software architecture. By the time I left, my resume cover statement was "Turning the corner from coder to architect." I knew I wasn't there yet, but I had a strong interest in that direction.
My next job was as a lead in modernizing a business-critical internal legacy app. It was my first time working in a team of 4 and using scrum, and I was leading the modernization effort. So my boss took a risk on me, but she said she was glad to have done so. Turns out I'm not too bad in a team (a pleasant discovery for me as well, being an introvert), and I ended up incrementally rewriting the majority of the system in under 2 years. The other dev mostly specialized in other things, but she waded in there too at times. I got to try some design and architecture bits and bobs along the way. And I never stopped pressing forward on learning architecture and design, often in my spare time.
I was also very fortunate to be co-located with the UX department. Not only were they fun people, but I really latched onto user experience as an important feature of any application.
Eventually the rewrite was done "enough" and the business wanted to switch focus on a deep integration effort with another product. I really liked my team, and I was not looking for another job. Nonetheless, I was asked to come back to a place I had previously worked in college. It was to help modernize their legacy system -- a monster which I had helped create years ago. Only this time I would have carte blanche on technology, architecture, whatever I wanted. I declined the offer at least once. But ultimately I made the really tough decision to leave, after 2 years and change. And initially the plan was to leave for a few years to help out that company and then go back to my previous company. (Believe me, I asked to make sure that was a thing.) That brings us to where I work now.
When I first came back on board 4 years ago, the plan was to do a big bang rewrite of the system. In the back of my mind I knew it was a bad idea, but there was general agreement that it was the best plan. It was also a siren song to start the architecture with a clean slate. However, since I had been gone the system had become pretty sprawling with a lot of apps integrated through a database. As I developed the new system, it became harder and harder to understand how we could possibly migrate to it from what we had. Eventually, the executives got tired of not getting business value from my expensive salary, and directed me to fix some really painful issues in the legacy app for a while. It was after that point, my manager and I agreed to abandon the rewrite. Instead we started implementing the good things we learned from the rewrite into the existing system. We made a lot of positive changes to ease pain for various users. (And we still have a lot of work to do, but we can at least see a path forward.)
The next series of events is pretty fascinating. I was really yearning to get more architecture experience. To recap: I was only supposed to be here a limited time. The original reason I came fell by the wayside. So, I figured they would let me go to hire a less expensive person to keep working on the system. I even told the director that at my next job I was ready to lead a team as architect. Not long after, several customers independently began asking us to develop a new product that wasn't directly related to our core business. My (hindsightedly stupid) advice to the director was "No, we aren't a software dev shop." But they persisted and we agreed. I picked the tools we used, and designed the multi-tenant architecture for the cloud. I hired 2 devs with no experience and trained them (mostly giving them time to explore). We lost one dev to greener pastures after a couple of months, but made our first MVP release in 6 months. Almost a year and a half from the start, we have a pretty decent offering, and we are talking about making it publicly available (so far we have gotten business through person-to-person pitches to industry contacts, and word of mouth). I'm getting around to implementing arch changes that I had planned but lacked time to do initially -- especially to enable scaling the infrastructure and our team. Other products are already in the works... looks like we might turn into a dev shop yet, and I might never leave.
We've used some of the same tooling and infrastructure from that to rewrite or add to some of our internal apps as well. Making them worlds better in function, stability, and appearance. These changes have been a big hit with our users and customers.
Of course, that's the sunshine and rainbow highlights. There's also the overwhelming stress of being responsible for the success or failure of the technical aspects. The nights and weekends reanalyzing your decisions for holes or researching for that next step or that missing piece you haven't nailed down yet. Sometimes I want to quit and go dig ditches for a living. :) And I by no means consider myself a seasoned architect. Although I studied the research and theories surrounding it for years, I've only made a beginning in the practical application.
Hope that helps.
Damnnn. Great comment.
What a story!
wait i already do this - "The nights and weekends reanalyzing your decisions for holes or researching for that next step or that missing piece you haven't nailed down yet" 😬 heh.
thanks so much for sharing, this is a very colorful path and had some unexpected pieces in it. i love that your company worked its way to abandoning the rewrite, and incorporated what you had learned into improving what you had. rewrites have their place, but replacing sprawling legacy apps is a lot tougher than people give it credit for!
I'm not sure about your situation. But for me, I never got the opportunity to be a "junior" developer and have someone else be ultimately responsible. There was no one else available but me in most places I worked. So, I also felt this way throughout my career... that if I didn't get it working, the effort would fail. It's not so bad as a solo developer on a single app here and there, but I find the stress much greater when my decisions play a part in company strategy and people's careers. To be honest, I find myself in paralysis sometimes... endlessly researching to get a picture of how every corner of the architecture works together before I even take a step. In particular, I try to thought-experiment each detail to uncover the obvious trade-offs as early as possible. But time being finite, I often have to move forward with my best guess. I need to rediscover the playful attitude with which I approached this stuff earlier in my career to make it more fun. Although it remains intensely satisfying to have created something that works well and meets a need.
I believe that large spaghetti systems make it nearly impossible to justify a big bang rewrite. There is just no way to account for all the side effects that are baked into the system. (e.g. App A depends on App B setting some data, but only sometimes.) The new system will miss a lot of edge cases because they look like accidents and noise. Therefore the cost of creating the new system also extends to adding missed edge cases for a while after it is first deployed. And that only gets you back where you were before the rewrite, with maybe a few new things added. Plus your users are angry with so much change at once. The right way is to carve off pieces of the system. That gives you a chance to dig into that area and talk to your users. Then you can not only modernize things, but you can also add value while you do it, and let users adjust in small increments. That piece gets deployed separately and its responsibility removed from the legacy system. Rinse and repeat. Smaller is easier to throw away and rewrite.
this is similar to my experience so far. at my last job i was a team of one. i had people i could pester with questions, but they were on a different team (read: under a different cost-center in the company) so questions were definitely not encouraged.
at my current job, i'm largely independent again (although my team is fantastic!). i'd love to be in a situation with more expected collaboration. so maybe these experiences can actually be good things :)