The Lone Developer Problem

Unmentioned reason: for the lone developer, the temptation to be "clever," or do interesting experiments is harder to resist. For me, sometimes that's driven by boredom. I've occasionally found myself switching paradigms ("This time I'm going to try a functional style (in python)...") just to keep things interesting, even if in the long run it might not be ideal. Even in the same project! Or, without the guardrails of peer criticism, I'll think "ok, this is a great time to try new library/framework X."

IMHO, there are some benefits to the above! Experimentation and trying new techniques/frameworks is how we learn and progress. The danger arises when the experiments congeal into half-baked production code.

> For lonely programmers, identifying the code that should be high quality (the one you will be looking at continuously) and the one is only there to fix a single problem is really important.

I feel your pain. I am the main coder, in a small team. There's one server guy (part time), and one semi-technical graphic designer (also part time), a couple of admin/marketing folks (also part time), and me (full, full time).

My software is really good, and I don't need anyone else to tell me it is or isn't.

That said, I am also quite aware that I have to make compromises, and that there are things that I'm not good at.

For example, I'm a higly advanced Swift programmer. I write Swift, every day (like, seven days a week, 52.14 weeks a year). I'm good with UIKit, and reasonably good with the other frameworks.

Server-side, I've been writing PHP for over 20 years, and never really got full mastery of it. I can write some very performant and robust server infrastructure (a lot of it lasts a long time, too), but I don't pretend that some kid couldn't code me into a corner.

But they might have trouble doing that, with Swift.

Doesn't stop them from being real judgmental, though. I suffered from that, myself.

Here's an example of stuff I do, now, that I would have sneered at, just a few years ago[0]:

    let distance: CLLocationDistance = CLLocationDistance(rawMeetingObject["distance"] as? Double ?? Double.greatestFiniteMagnitude)

That uses a nil coalescing operator (??). In some cases, I can go through several of them, on one line (cascading nil coalescing operators).

That says that I need to get something from the "distance" key of a parsed JSON Dictionary, and, if it is not available (either as a key, or as a value that cannot be coerced into a Double), then I should return the maximum Double value (so it will blow up the distance sorters).

Here's a slightly more involved example (from a proprietary app):

    let defaultDict: [String: Any] = [
        Keys.useTestServer.rawValue: values[Keys.useTestServer.rawValue] ?? defaults.value(forKey: Keys.useTestServer.rawValue) ?? Self._useTestServerDefault,
        Keys.resetPrefs.rawValue: false
    ]

If there's no default value in either the runtime, or the app defaults, then I use the hardcoded default. The reset is always false, after the first run.

That's actually fairly typical advanced Swift. I used to rail against it, but now, I do it all the time. I also tend to use tail closures a lot (that's when you declare a closure at the end of a function parameter list, so you can simply open the closure as a function result). That's also something I used to rail against.

If someone wants to maintain my code, then they need to have some decent chops. Usually, that's me. I will often revisit code that I wrote, six months ago (or more), and have learned how to read it. I write code that I want to see again; not some junior programmer.

[0] https://github.com/LittleGreenViper/LGV_MeetingSDK/blob/e91b...

Single developer work is akin to single point of failure. This article brings to memory a famous article from an author name that it eludes me at the time. The article reads a line that goes alone this idea: "With enough eyeballs, all bugs are shallow". You wouldn't board a plane that was built by one single guy right?

The over riding premise seems to be, get feedback. Always a good reminder.

However, this can be taken too far and contributed to me leaving my last job. I was pushed for review on too many things, in my opinion. It got to the point where it was a waste of time trying to decide anything for myself. I had to invite people from multiple disciplines in the off chance a good idea would surface. Not only did it demoralize the experts, it slowed progress from weeks to months with no appreciable difference in quality. Most meetings were met with little or no feedback because the people involved had no experience in the stack. Most suggestions were to solve the problem within their own area of expertise, the web service guy would always suggest a web service, the DBA would always suggest TSQL, etc.

What I would recommend is develop the ability to recognize when more feedback would be beneficial and schedule a review or meeting for that and act like a working professional and take responsibility when things don't go perfectly. Which suggests the real root of the problem and need for getting feedback all the time...

> In reality it becomes design by committee, worst of all worlds.

And then there is the special hell of projects written by groups of hurried physicists, zoologists, linguists or other non-IT scientists.

And below that, heirloom university software projects where every generation builds on the previous iteration, without ever cleaning it up.