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 softwar...
For further actions, you may consider blocking this person and/or reporting abuse
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.