11–20 of 151 posts
At work, not so much, as it's mostly very rushed, badly designed software.
Not even my own.
Past me however, is a total c##t that seems to take joy in solving their problems by making them a massive problem for me when the chewingum and dollar store masking tape inevitably fall off.
Not everything was perfect, but it was much better than the code changed by future generations which tried to mess it up with almost every commit, in the name of "it's good enough", "consistent style is not needed as I can still read the code", "what tests?", "we can refactor later"...
Every variable and function was explained in a series of physical manuals in excruciating, and up-to-date, detail. The manuals had index lists by name, function, type and concept, making it ridiculously easy to find exactly what you were looking for. The documentation felt almost like reading Knuth's Art of Programming. It explained not just how a function worked, but also the dependencies and how they worked on that particular hardware, including pieces of the FORTRAN standard library.
On top of that nugget of most people's fantasies, there was actually a test suite! It wasn't written by the original authors, and had been pieced together over the years. But it was a testsuite for code running on a mainframe the size of a small room. Since when do you ever get tests for code written in the 70s!?
Working for CommBank was hard - the standards for absolutely everything that they have and do are A-grade. A single complaint from a coworker or customer can land you in front of a review board. But the work they produced, at least what I saw, is absolutely worth it.
Maybe "inherited" is a strong word, but some of the open source projects I contributed to were beautifully crafted. Django is one such example, on all fronts — docs are great, there are tests, and so on. At work, not so much, as it's mostly very rushed, badly designed software.
What's stopping you in improving the situation? Time pressure or unwilling colleagues?
I think their inexperience and lack of hubris made them go to a lot of effort to be idiomatic in a language they were using for the first time.
1) Working (professionally) on a project that happens to be open source: https://github.com/metabase/metabase/
2) Coming to a Rails project mostly written by a very senior 7-person team. There was still a fair amount of jank (mostly from seed-round assumptions that weren't holding up when I joined after the Series A) but it still followed The Rails Way and nothing was too gross. It also helped that everyone important was still at the company and available for questions.
PS on (2): Seven of those original eight dev are now gone, including me; the median years of experience has gone from 8-10 to 0-3; the team size is at least 40 and I think more; and my understanding from friends still at the company is that the codebase is in general a flaming mess.
The project lead was incredibly impressed that I was able to make a solid contribution check-in on my first day :-)