I am in my late 40's, I have been coding since I began uni in 1987, I have a Computer Science degree. When I got out there 25+ years ago I was all about doing things the best way, code reuse, refactor etc to get things just right. Most younger devs are. It took so much time getting the environments perfect, unit tests, etc. The customer paid for that, my managers must have been tearing their hair out watching us faffing about doing crap that ultimately didn't lead to a better experience for the customer. I am much more experienced now and live off my own skills, I have about a dozen apps on the iOS app store the number of users is 7 figures, they bring in good coin. The code behind them is crap, has not been unit tested, there are not massive build environments or anything, I don't write for reuse until I need to reuse, I acceptance test it myself. My users love the apps. They are bug free and reliable, and users often leave reviews to this effect. Experience is everything. I'm old school now, back in the day live fixes to production data were nothing, no-one would ever do that now. I met older gen devs than me, they did not then and do not now even use source control. Yet their releases were and still are 100% stable and bug free. They are still paid a premium for their thoroughness. As I grow older, I see more value in keeping it simple rather than miring down the work in process and the pressure of doing it perfectly. There is little value in it for the customer if the dev is experienced. And I'm happy that these premium jobs are now coming up for me.
I'm about your age, and I agree with everything here. My "process" is thinking through problems thoroughly and being careful. I used to be able to find whole teams full of people who worked like this, and during that time I worked on at least 5 outrageously successful, stable products, with no automated tests and no process other than test it manually and check it in. Eventually, time moved on and (mostly younger) people decided that this was impossible, refactoring without unit tests is impossible, humility demands you admit to sucking at programming just like everybody else, etc, etc. So now I mostly avoid working at companies at all, because I can no longer find teams that don't pour 80% of their energy into processes and methodologies.
> My "process" is thinking through problems thoroughly and being careful.
I'm saddened by how thinking has become strangely uncommon. I've seen many teams where people either type code or have quick chats where they decide what to do on a whim.
It bugs me as well. The problem is that while 'just do it' is intuitively appealing, thinking things through is a discipline that needs to be actively chosen and learned, but who is teaching that? You don't have to spend much time in the software development blogosphere to see that there are quite a few people who seem to believe that thinking ahead is waterfall is anathema. This may not be a proper interpretation of Agile/TDD (I could argue otherwise), but it seems to be a fairly common one.
For the OP, I would say the point is to be skeptical of dogmatic claims about the proper way to develop software.
I'm > 40 and have a very similar story. I mostly work alone now , have never written a unit test in my life and have a few very large mission critical apps with many millions of dollars of revenue ti d to them. Mobile, native desktop and web. I take my time and thoroughly think through a change and the implications to the systems. I only try to build reusable code if I'm on my 3rd time of trying to use it. Not trying to build a perfect piece of engineering easily cuts my development time in half
I'm not sure where all this process came from, but it sure does cost the business a ton of money without much return. I would theorize it could be an attempt to abstract the developer from the business process so the business isn't so beholden to one or a handful of people.
On a side note, I embrace source control. It allows me to run down a rabbit hole and not worry about having to get myself out of it.
To the OP: Look at popular code bases and see how they are organized. Run your debugger through them and see how they work. Organization is the key to maintainability. DRY (Don't repeat yourself) and KISS (Keep it simple, stupid) are your friend. Like anything, the more you do, the better you will become.
So the quality is reliant upon your 'personal software process' or individual discipline while you work rather than upon practices like test-driven development, continuous integration, etc.?
I work in an environment like this. The need for TDD and CI are greatly reduced through the use of modular code design, encapsulating major logic/system units with a uniform API, and coding standards. The emphasis is inherent program quality as opposed to external quality checks. One consequence is the discouragement of individual creative flourish: "clever" code is discouraged, and descriptiveness is favored over terseness. This makes the code easy to understand, to modify, to check for correctness, and to reason about. Of course, there are still unit tests and integration tests, but their role is more low level and less visible.
