Stories about Software


Should I Incorporate? The Knowledge Worker’s Dilemma

Happy Monday, everybody.  To help prolong your procrastination over morning coffee just a little bit longer, I’ll offer you the latest installment of reader question Monday.  Today, I answer a question that many reading my blog probably have: should I incorporate?

Here’s the actual question, as I recorded it.

What is the cost/benefit of incorporating? Should I just keep paying for domain/hosting through my [credit card], or would it be worth the hassle to move to a real business?

As you can see, I’ve generalized a bit in order to make it more broadly applicable.  But I’ll speak to all salient points through the post.

Should I Incorporate?

Yes.  Alright, post over.

Just kidding.  At least, I’m kidding about the “post over” part.  I do think that you should incorporate.

“But you don’t know anything about my situation, my job, or my life!” you protest.  And, while that’s true, I’d argue that I don’t need to know anything about it, assuming you’re a knowledge worker.  To make my case, let me now speak explicitly to costs and benefits, as requested.

Should I incorporate? The monopoly guy here thinks the answer is yes, and so do I.

Read More


The First DaedTech Digest

I mentioned this idea in a post I wrote the other day, the idea of a digest style of post.  So today, I’d like to give it a try.

You see this sort of thing a lot, all over the place.  So-called planet sites have been around for a long time, aggregating community-related articles into a single place.  Examples include one of my personal favorites, the Morning Brew.

There’s just one difference in what I’m proposing.  Instead of gathering stuff that others have written, I’m going to digest the stuff that I’ve written.  In the last year, we’ve turned my paid blogging for other sites into a tech content business, taking blogging from a side hustle and hobby to a professional gig.  So, I write a lot of blog posts.

Historically, I’ve simply cross posted these with canonical linking, leading in with “editorial note: I originally wrote this post for…”  But I’m thinking of taking DaedTech in a bit of a different direction than just generalized software-oriented blog posts.  More on that later.

The point here is that, instead of pushing one of these cross posts out per day, I’m going to do a single digest post per week containing posts that I’ve made.  I have about 90 backlogged drafts in my folder, so at first it’s going to be posts I made some months back.  But sooner or later, I’ll catch up and give the posts I’ve published in the last week.

But anyway, without further ado, here’s the digest.

Some Posts to Check Out

  • This is a piece that I wrote for the Monitis blog.  It’s about threat modeling and the woes of being an e-retailer and guarding yourself against criminals and ne’er do wells.
  • I wrote a post for TechTown that was a primer about unit testing in C#.  It gives you a back to basics explanation, the value proposition, and the simplest imaginable examples of writing unit tests.
  • This is another post that I wrote for Monitis. It’s about the C# IEnumerable construct and how, if you misunderstand it, you can kill your site’s performance.  This has to do with how IEnumerable can encapsulate deferred execution, and that it only promises a strategy for obtaining items, rather than giving you those items.
  • I wrote this post for SubMain.  It’s about how something that’s seemingly inconsequential — spell checking your code (specifically, C#) is more important than you might think.  There are subtle things to consider that you might not have considered.
  • This post is actually going to become part of Microsoft’s official documentation!  Seriously, no kidding.  Bill Wagner wrote to Patrick and I about this post, and it’s now in their documentation build on Github.  Anyway, I wrote it for NDepend, and it’s a walk back through past major version of C#, reflecting back on nearly 2 decades of the language.  It was a fun journey down memory lane.

And, that’s it.   Happy reading, and happy Friday!


The Programmer Skill Fetish, Contextualized

I am currently considering something of a content pivot for DaedTech.  I haven’t really decided anything for sure yet, but I’m leaning toward putting cross posts into digest format once per week and then doing fewer posts, but ones that are more focused on developer empowerment and the efficiencer dream.  Your feedback on this is entirely welcome in the comments or on Twitter or Facebook or anywhere, really.  I’d honestly like to know what you think.

I mention that because I think I need to refocus a little on some hypotheses that underpin all of this.  In the time between writing Developer Hegemony and now, I’ve found myself distracted by changing my lifestyle, selling a house, starting a couple of businesses and, well, life.  But throughout that time, I’ve given some thought to what I ought to offer people with this site.  Should I continue (against the advice that I offer everyone else blogging with purpose) to keep the blog as a chronicle of my many thoughts?  Or should I orient it around a theme in which I help people solve some kind of problem.

And I’m leaning toward trying to solve a problem.

So back to the hypotheses.  First one that I’ll mention is that programmers should specialize and seek options outside of full time employment.  (Not as in immediately making it your goal to escape the rat race.  Rather, make it your goal to have options outside of serving at the pleasure of some single employer.)  The second one, following from that first, is that we focus on programmer skill to the point of fetishizing it.  And, we do this to our detriment.

The Known, But Unheeded, Career Wisdom for Programmers

Let me lay out a few points that surround the issue.  None of these will probably be especially new to you, but taken together, they’re interesting.

  • You often hear some variant of “part of being a great developer is knowing when NOT to write code.”  In other words, being really good at writing code helps no one if you code up a useless product.
  • Successful “entreprogrammer” John Sonmez, in promoting his “Soft Skills” book, often talked about how he wasn’t successful because he was the best programmer, but because he learned the material that he was communicating in the book — strategies for business and dealing with other people.
  • In most organizations, it’s not necessarily the “best” programmers that wind up with higher pay and vanity titles like “senior,” “tech lead” and “architect.”  It’s generally the longest tenured ones.  Long time readers will remember my writing on this subject.
  • Businesses and non-technical people often don’t listen to the “best” developers, often because those developers take pride in spewing jargon and being indecipherable.
  • We can’t even define “best” programmers.  Do a google search on it.  Page one alone promises more than 100 answers.  These include technical knowledge, but also things like “positive attitude” and “good communication skills.”

Put all this together, and you have an interesting picture.  The business world and the greater non-programming world in general values one thing.  Programmers, when we get together, value something different.  We’re fully aware of how outsiders value us, but we just can’t resist the impulse to compare ourselves to others with code competitions, programming challenges, data structure interviews, and claims that we’re “10x” better than others.

The Skill Fetish, Explained Indirectly

This brings me to what I think will be the fun part about writing this post.  I want to use a metaphorical story to help bring context to why we do this, and how shotgun-blast-to-our-own-feet it is.  It’s easy enough to sit there in the waiting room of GiganTech, waiting to see if they deem you better at O-notation than the other 430 applicants, and get caught up in all of this.  It becomes normal.  So I’m going to draw a parallel to a different line of work.

I did this to an extent in Developer Hegemony, but as part of a larger point about journeyman idealists.  Here, I’ll get more direct.

The teenage gym rat makes an interesting metaphor for our preoccupation with programmer skill.

Read More


How to Deal with an Insufferable Code Reviewer

Time for another installment of reader question Monday.  Today, I’m going to answer a short and sweet question about how to deal with an “irksome” code reviewer.  It’s both simple, and fairly open ended, making it a good candidate for a blog post.

How do you deal with peer code review and irksome coworkers? Any trick?

Okay, first things first.  This could cover a lot of situations.  Theoretically, someone could be writing extremely problematic code and finding coworkers “irksome” simply for pointing that out.  And, at the complete other end of the spectrum, the code may be fine but a toxic culture creates endless nitpicking.  In environments like this, the code review becomes an adversarial activity, as much about political games as about code quality.

So you must introspect and also think in terms of your goals.  What is it that’s irking you, exactly, and what is the desired outcome?  I’ll frame the post roughly in terms of goals, and my advice for achieving them.  Really, that’s the only way to do it, since code review processes vary so widely from team to team.

A Bit of Perspective on Code Reviews and Code Reviewers

Before going into any advice, let’s consider the subject of code review itself.  There are two conceptual levels at play.

First, let’s talk about the obvious one.  A well-conducted code review process helps with code quality and it helps developers learn.  In his book Code Complete, Steve McConnell cited a study that found “formal code inspection” to be the most effective defect prevention method.  This put it ahead of even automated unit tests in the study.

But, beyond that, code review has important human ramifications as well.  People learn and share knowledge through this process.  And they use it to prevent the kind of defects that result in frustration for the team: rework, embarrassment and even a need to come in on weekends.  People with a stake in the codebase get emotionally invested.

There’s also another, more subtle element at play, however.  I talk extensively about these terms in my book, Developer Hegemony, but you can read a brief primer here.  Software developers (to my endless irritation) are pragmatists (line-level laborers) with almost no actual influence in the corporate world.  When you participate in the so-called “technical track,” you typically never have people reporting to you, earning only developmental titles that include things like “senior,” “tech lead,” and “architect.”

So often, the only simulacrum developers get of actual organizational power comes during interviews and code reviews.  Decent human beings handle this well, looking to mentor and teach.  But there are a lot of less-than-decent human beings out there, who relish these opportunities to wield what little power they have.  The phrase, “a little man with a little power” comes to mind.

An angry code reviewer

Read More


Fundamentals of Web Application Performance Testing

Editorial note: I originally wrote this post for the Stackify blog.  You can check out the original here, at their site.  While you’re there, take a look at their offering that can help you with your own performance testing.

Software development, as a profession, has evolved in fits and starts over the years.  When I think back a couple of decades, I find myself a little amazed.  During the infancy of the web, hand-coding PHP (or PERL) live on a production machine seemed perfectly fine.

At first blush, that might just seem like sloppiness.  But don’t forget that stakes were much lower at the time.  Messing up a site that displayed song lyrics for a few minutes didn’t matter very much.  Web developers of the time had much less incentive to install pre-production verification processes.  Just make the changes and see if anything breaks.  Anything you don’t catch, your users will.

The Evolution of Web Application Testing

Of course, that attitude couldn’t survive much beyond the early days of dynamic web content.  As soon as e-commerce gained steam in the web development world, the stakes went up.  Amateurs walked the tightrope of production edits while professional shops started to create and test in development or sandbox environments.

As I said initially, this didn’t happen in some kind of uniform move.  Instead, it happened in fits and starts.  Some lagged behind the curve, continuing to rely on their users for testing.  Others moved testing into sandbox environments and pushed the envelope besides.  They began to automate.

Web development then took another step forward as automation worked its way into the testing strategy.  Sophisticated shops had their QA environments as a check on production releases.  But their developers also began to build automated test suites.  They then used these to guard against regression tests and to ensure proper application behavior.

Eventually, testing matured to a point where it spread out beyond straightforward unit test suites and record-playback-style integration tests.  Organizations got to know the so-called test pyramid.  They built increasingly sophisticated, nuanced test suites.

Web Application Testing Today

Building upon all of this backstory, we’ve seen the rise of the DevOps movement in recent years.  This movement emphasizes automating the entire delivery pipeline, from written code to production functioning.  So stakes for automated testing are higher than ever.  The only way to automate the whole thing is to have bulletproof verification.

This new dynamic shines a light on an oft-ignored element of the testing strategy.  I’m talking specifically about performance testing for your web application.  Automated unit and acceptance testing has long since become a de facto standard.  But now automated performance testing is getting to that point.

Think about it.  We got burned by hand-editing code on the production server.  So we set up sandboxes and tested manually.  Our applications grew too complex for manual testing to handle.  So we built test suites and automated these checks.  We needed production rolls more frequently.  So we automated the deployment process.  Now, we push code efficiently through build, test, and deployment.  But we don’t know how it will behave in the wild.

Web application performance testing fixes that.  If you don’t yet have such a strategy, you need one.  So let’s take a look at the fundamentals for adding this to your testing approach.  And I’ll keep this general enough to apply to your tech stack, whatever it may be.

Read More