I originally posted this on my blog about a year ago. If it's interesting to you, I post new content there roughly weekly.
I used to write software for a living. I did that for a lot of years, as a matter of fact. And, in doing so, I learned a lot about how to write software.
But I learned this from the perspective of, well, a wage software developer. Today, I'd like to reflect on how my view has evolved over the last number of years.
Software as a Software Developer versus Software as a Business Owner
As longtime followers of this blog know, I've had a meandering career. I started this blog as a software developer, new to moonlighting.
Eventually I moved into management and then started doing developer training activities. From there, it was a number of years of consulting. And finally, these days, I'm mostly running a business that is growing rapidly.
I say all this not to treat you to an unsolicited autobiography, but rather to set the scene and to help explain what I've been doing between my last full time software development gig and now.
These days, for Hit Subscribe, I've started writing software again. I don't do it full time, by any stretch.
But I am building a line of business app used directly by four of us and indirectly by something like 30 people. So it's not my primary living, but it's not trivial either, in terms of importance or scope.
Dedicating some time to this has caused me to reflect on how my perspective has changed.
Don't get me wrong. I never stuck my head in the ground pretended "the business" didn't exist or didn't matter.
But then again, I never was the business, either. It was never my money in play.
Now that it is, here are some musings. And please bear in mind that I'm not teeing these up as lessons you learn.
They are simply how my perspective is different.
1. I Ask, "How Does This Not Exist?!" A Lot.
I won't go into a ton of detail about the app I'm building. It's no secret -- here's the github repo, if you want. It's not interesting enough to folks outside the business to describe in detail.
What I will say, however, is that you could argue that there's a COTS out there I could use instead. I've researched this a bit and punted because of cost and because I'd prefer a degree of extensibility that would probably be impossible.
So I decided to build instead of buy. But I didn't decide this lightly.
And that philosophy carries down to more granular levels.
In my software pro days, I'd have snapped my fingers and said, "aw, shucks, I guess the perfect client-side grid thing doesn't exist, so I'll just build my own!" These days, not so much.
Whether it's a framework, an architectural construct, a library, or a user control, I find myself thinking, "someone has to have built this by now. It's friggin' 2019 -- how does this not exist yet?!"
I want to spend my time building out business logic and serving the app's specific value proposition. I don't want to write the world's 183,663rd date picker.
2. I Don't Think Building Things Yourself Builds Character
This next point builds logically on the first. I don't want to build yet another date picker because it's a waste of time I could spend on other things. I'd rather one just exist.
And consequently, I also don't think building my own somehow builds character for me as a programmer.
There's an understandable desire to know how everything works under the hood. If you write web apps, you'd better yourself by writing your own web server to really understand how your web apps work.
Do you write web servers? Try writing your own kernel logic or your own operating system.
This is kind of extreme, but it reflects a sentiment. And I remember sharing this sentiment.
Building something of questionable business value might not help the bottom line or your immediate situation. But it would give you a broader base of generalist knowledge to use in your career.
Well, it's no secret that I've soured on genearlism in the extreme. I don't think that writing a date picker improves my prospects short term or long term.
Might it make me a slightly better generalist programmer? Sure, maybe.
But why not build something that actually serves your career, instead of miscellaneous "practice?" I'd rather get better at automating and solving deep problems in my chosen domain, and make myself increasingly marketable as a specialist.
3. Don't Speculatively Abstract Anything
Moving away from the idea of your own skill set and from reinventing wheels, let's talk about actual software design. My take on that has changed a lot, too.
Back in the heady days of obligatory N-Tier architecture in enterprise Java, I was a believer.
Want to build a toy app to sort the music files on your hard drive? Well, the first thing you need is your data access layer, domain layer, service layer, presentation layer, and markup, of course.
And interfaces. Interfaces everywhere.
Sure, today you might want it to sort MP3 files on disk, but maybe tomorrow you'll want it to be links in a relational database or blobs in a document store. If you interface all of your layers, you can swap out your entire persistence model without ever touching anything else!
Would you ever want to? Who cares! You can do it!
Before I left the world of wage software, I drifted away from this and toward YAGNI along most others during the late 2000s. But I still fretted over architecture from the get-go.
You want interfaces because unit testing. You want at least some conceptual layering.
These days, not so much. I want to test drive my code, and if I can do that, fine.
So I don't interface anything until I'll have multiple implementations. I don't layer things until I have an actual use case for varying things above and below independently. I don't create abstractions until they solve problems.
So I use Entity Framework and manipulate a context right there in my controller, and I keep doing it until I have a persuasive reason not to. I don't have time for speculative best practice design.
4. Technical Debt Can Be Technical Leverage
Are you familiar with the difference between debt and leverage? It's not just "debt is what Millennials have and leverage is what wealthy Boomers have." It's about the reason that you owe money.
If you borrow $20 from me for a pizza that you subsequently eat, you have debt. You've taken that pizza and turned it into... well, let's just say something that probably has no monetary value. You owe me $20 and you've used the money you borrowed in a way that gives you no head start on repayment.
But let's say that instead of buying a pizza, you take $20 from me and buy a share of stock.
You still owe me $20, but you now have an asset worth (for the moment) $20. You could pay me back at will.
But what's more, you have an asset that might appreciate. It might even appreciate more aggressively than the interest you pay me on the loan. This is leverage.
Leverage is a more strategic play than debt.
This is true in finance, and it's true in your codebase.
In my younger days, I viewed technical debt exclusively as "slapdash design" and a failing of the team. I didn't distinguish between tech debt and tech leverage.
But now I do.
I was using a library recently whose untestable design bleeds into the code using it. So I confined use to an isolated area at the edge of my codebase. This worked, but a series of events started to force business logic into these untested little methods.
I went with it for a bit because we needed a series of relatively quick changes to facilitate work that couldn't wait. As I did this, I understood that I needed to think about an isolation framework or a wrapper for the library I was using. I understood that each commit where I didn't do that would make things more time-consuming later.
But for a while, I went on anyway. And then, finally, when there was downtime on a weekday, I paid the piper.
This was tech leverage. I'd created the aforementioned downtime by incurring technical debt. I'd saved more time than I'd cost myself, and I got the code back on track so as to keep the feature delivery curve flat.
5. My Pride in My Work Product is Irrelevant
And finally, one last evolution in my thinking. You could probably call this "lean" or use a pithy phrase, like, "if you're not ashamed of it, you waited too long to ship it," or whatever. But I have a different take.
I think of it as a pragmatic recognition that "pride in the code" is irrelevant to the goals we have with this business.
Oh, don't get me wrong.
I do take some pride in delivering something quickly or coming up with a compact, readable way to refactor a method. And, I'd rather push something into production with a snazzy UI.
But those are vanity concerns -- not business ones. For the business, my pride doesn't matter.
So I can't think things like "if I were a good programmer, I'd do this best practice, or defensively code against that, or have a diligence checklist." Instead, I have to frame all of those things through the lens of business value and return on investment.
To circle back to an earlier theme, is it embarrassing to push something into production that requires us to hand-type dates instead of using a date picker? Sure, kinda.
But will I omit the date picker if the people using the app tell me that it would save them almost no time? Yes, absolutely.
I guess, in the end, this detour from programmer to business owner and back again has created an important distinction for me. For hobby projects, I sharpen saws while I automate, hone my skills, and make things I'm proud of. For projects with a commercial interest, I code like an economist.
I also field reader questions on the blog. If you'd like to ask a reader question, you can do so at the "ask me" page.
Top comments (16)
Hi Eric,
Thanks for your post! It's interesting because it seems to go against the grain in a lot of ways.
All your points got a response out of me, so I thought I'd share.
1. I ask, "How Does This Not Exist?!" A Lot.
I've done the same thing a few times now. Sometimes the only things on the market satisfy 80% of what you need.
Sometimes there are too many options to assess with no clear winner. I find that it's often a tough question to find an answer to.
I have reinvented the wheel before though and it was quicker than learning new technology - in terms of installation, development, and maintenance -
it was also fit for purpose. Many tools you find online solve a generic problem and it's a lot of overhead to fine-tune it to your needs.
2. I Don't Think Building Things Yourself Builds Character
I disagree.
I would love to write my own compiler or database, just to get a better idea of the underlying principles.
Just not on business time. You have to find a balance between putting the business needs first vs. your own curiosity.
I do think that it says more about your character as a developer if you work on a side project in your free time rather than just staring at a Netflix show.
3. Don't Speculatively Abstract Anything
SOLID principles disagree with you here. Perhaps I'm still drinking the Kool-Aid at this point in my career but you need to follow a methodology when you're working with other people.
It's like road rules: Imagine people started driving on the wrong side of the road, disobeying traffic lights, etc. during rush hour.
If they did it at 3 am when no one else was around, they'd get away with it and no one would get hurt.
Because it's your codebase and the team is relatively small, you've gotten away with it.
4. Technical Debt Can Be Technical Leverage
It can be but often isn't. That being said, perhaps it depends on what we define as technical debt. True technical debt, sure. A mess? Never.
5. My Pride in My Work Product is Irrelevant
Ivory towers of code don't give you business value, true.
However, no one wants to work on a crappy codebase.
I think your team will be more productive if there's a certain standard maintained.
That being said, I know what you mean. From a business aspect, you need to deliver and you can't always make things exactly as you'd want.
I generally follow the advice of Kent Beck's quote: "Make it work, Make it right, Make it fast" - You start with the first but the rest are as important for the overall health of your codebase -> product -> business.
Regarding (2), I'm not sure that the only choices in your free time are a "character building" re-invention of the wheel or watching television. Instead of building the world's 90,000th compiler, but probably not as good, why not build a plugin or SaaS that someone might actually use in your spare time?
Regarding (3), I'm curious as to which SOLID principle calls for speculative abstraction. I've never seen an argument that SOLID and YAGNI are at odds. Usually, in my consulting travels, the sorts of clean-code-minded craftsman types that advised companies would tout both of these concepts together.
BTW, looks like you put a lot of thought into the responses here -- if I were you, I'd flesh them out into a post here :)
2) Hahaha, yes I would think that it would be more useful. I'm not saying that you should go and martyr all your free time by redoing what has already been done, only that it's fine to do so if it's an exercise for you to learn something.
3) Maybe I should have clarified that what I was referring to specifically was this: "And interfaces. Interfaces everywhere.
Sure, today you might want it to sort MP3 files on disk, but maybe tomorrow you'll want it to be links in a relational database or blobs in a document store. If you interface all of your layers, you can swap out your entire persistence model without ever touching anything else!"
You seem to be speaking against the Interface segregation rule in SOLID here. I agree that arbitrarily abstracting away things for the sake of it or just to follow some "best practice" doesn't make any sense. But I think that having code that is flexible enough to swap out portions is pretty nifty. Not necessarily in order to change the implementation, but at least to be able to mock up concerns and do unit testing.
Thanks, maybe I will :)
Very true! I know exactly the kind of code you mean: Copy-pasting is everywhere (down to the typo in the comments); subroutines are named "oldMethod", "newMethod" and "reallyNewMethod", the most recent of which is 14 years old. Someone has, effectively, handed in their first-draft. Working in that kind of codebase is like wading through treacle. Nothing happens quickly.
That said, I have questions about the Make it right part of Kent Beck's quote. It needs a proviso: (until wrong). I tend to reach a point during refactoring where I think "Does this code actually need to be any Righter?" That's usually my sign to stop -- I'm no longer adding value. I've crept into ego-project territory, exactly as Erik describes in his post. Sure I can keep tidying, but doing so would be wrong.
Ultimately, I guess the people who have this kind of debate don't tend to be the problem. At the very least, their crappy code will be considered crappy code. They will be able to justify their decisions with something more than a shrug and a yawn. And hopefully, someday, they'll go back and make it right (until wrong).
You would have to define what "Right" means to you.
Overly academic and difficult to follow is not what I would strive towards.
Code, like all communication, needs to be simple in order to be effective.
Totally agree.
Learning to simplify is probably the most valuable skill I've picked up over the years. The question "How can this be made simpler?" has served me extremely well. Particularly, as you say, when communicating -- be it in code or even just an email. I often think of the Blaise Pascal quote: I'm sorry I wrote you such a long letter; I didn't have time to write a short one.
"I'm sorry I wrote you such a long letter; I didn't have time to write a short one." - Classic XD
I love Mark Twain wisdom, regardless how how deep it's threaded in any comments section ❤️ (It's also the story of my life)
Kudos for digging this far into the comments, Erik! It's a fantastic quote ... even if I'm never sure who it's attributed to. (I'm sure at least one source will say it came from Albert Einstein.)
Thank you Erik, it makes lots of sense. But where do you start if you want to create a business while also honing your developer's skills? Is it at all possible for a fairly new developer to bypass the "employment" phase and go straight to independent entrepreneur status without just being a freelance?
Honestly, in some ways I think it's probably better to go straight to entrepreneur if you want to build something like a SaaS. The obvious downside is that you'll be simultaneously learning business principles/practices and software principles/practices, which is probably kind of a firehose.
But the upside (and I say this as someone with over a decade of corporate programming experience) is that a lot of lessons that help you become a good corporate software developer teach you to be a bad business owner. You wind up with a lot of stuff to unlearn (like preoccupation with tools/frameworks/stacks, for instance). I wrote a post about this once, if memory serves -- if it's interesting, I can try to dig up a link.
Yes! Thank you. That would be lovely. Do you see many other developers desiring to become independent? Or they are mostly content with securing a corporate career?
In a sense, I'm the wrong person to ask about this. My readership demographic for my site skews heavily toward senior developers looking to become consultants/freelancers/business owners, and those folks write into me with reader questions pretty steadily. So, yes, I see a ton of developers who want to go indy, but I'm probably experiencing a lot of sampling bias, so caveat emptor :)
As for the post, I found it. Looks like I wrote it about a year ago, musing about how salaried work can teach you some bad lessons about going independent: daedtech.com/employment-teaches-yo...
Thank you, Erik. I have found your post quite original. It does relay a different viewpoint than what I have found so far. I am referring particularly to the subject of passion as a selling point. I image you would still want to be somewhat passionate about what you do, otherwise, it might be a drag, but I see how that would not be a winning business proposition for a client. I will read more of your content as I see you have a very practical and clear approach to the field. It is amazing that you have a content generation company. I come from content myself, having been the editor in chief and a journalist of some major computer magazines for a while. I know very well what you describe as priorities in content generation :)
It's a very interesting article, thanks Erik. Your last point is particularly interesting. Yes, (y)our pride is irrelevant to the business. That's completely true.
But how much is the business' pride relevant to the developer on a salary? Especially if we don't talk about a startup.
I could ask a simple question.
"Bob, [...] I don't see another dime, so where's the motivation?"
Thanks for the kind words!
To address your question and Office Space reference, I'll draw on the rather cynical perspective I have on most salaried software jobs. I have a taxonomy of corporate workers that categorizes someone who cares about "the pride of the business" as an idealist: someone who loses perspective on their own self-interest because they get caught up in the company's culture. These folks are prone to working long hours for no actual, discernible benefit.
I don't want to be that person and, as a business owner, I also don't want to employ that person, because it's exploitative. Convincing people to work long hours and give free value in exchange for questionable/vague outcomes down the line ("I'll remember this at your next performance review!") isn't something I support.
As a business owner/coder, I set aside my pride and ask what's in the business's (and thus my) best interests. As an employee, I'd set aside pride and ask what was in the best interests of my career/advancement/prospects. In both cases, those may line up with delivering visibly awesome stuff... but they may also not.