DaedTech

Stories about Software

By

Your Specialty Should Be Easy to Explain

I know, I know.  I’ve been on a bad run lately with doing reader question Mondays on Tuesdays.  But I have what I think of as a pretty good excuse.  For my wife’s birthday, we spent the weekend in New Orleans, dining out, listening to live music, and exploring the city.  I don’t think I cracked my laptop, let alone had time to write a post.  C’est la vie, no?

Anywho, on to the reader question.  I’ve been talking a lot to people about this, so I’m going away from the typical FIFO-ish approach and am pulling a question from the comments of a recent post.

Great article. I’m a Software Engineer currently focusing on Machine Learning and Natural Language Processing (NLP). When I think about specialization, I always have trouble in the granularity of it.

I’m working on difficult NLP problems so I think I have something there, but is NLP a specialization or is it too general? What could be the right specialization? some branch of NLP like Natural Language Generation or some vertical like “Real Estate”?

I’m not sure about this process, I guess that you start at the top level (NLP for example) and then you start getting some information about which path to take, kind of organically.

What do you think?

Good questions, all.  And thinking about how to answer this brought into focus that I might be muddying the waters when I use the term “specialty” in some contexts.  To clarify, I’ll go outside of the software world with a hypothetical story.

The What-Do-You-Do Conversation at a Party

First off, understand that I’m going to take some liberties here to talk about a domain in which I’m a relative novice: cooking.  So if you’re a serious chef or even a seasoned amateur, I make no pretense that this will hold up to much scrutiny.

That said, imagine the following conversation at a dinner party.

Alice: Hi there. I’m Alice.  It’s nice to meet you, Bob.  So, what do you do?

Bob: Well, I’m very into cedar plank techniques lately.  It’s become my specialty.

Alice:  Huh.  So, I’m sorry, what do you do with these cedar planks?

Bob: It’s a roasting technique that actually imbues a smoky flavor, so you kind of get the best of all worlds: smoking, grilling and roasting.

Alice: So, you’re a cook or something?

Bob: Yes, I’m a chef.

Alice: Oh!  Where do you work?  I should come try your food sometime!

Now, this conversation probably wouldn’t happen in real life.  And that’s because chefs (and people in most non-programming domains) easily adjust for context and know how to talk to their buyers.  But the world has coached us as programmers to instead impress our peers.

We think of specialty and niche in terms of creating such a granularity of expertise that nobody understands what we do, including our peers and competitors.  But we should be heading in the opposite direction, like Bob through the course of this conversation, as Alice dragged information out of him.

Specialty vs Competitive Advantage

So what is Bob’s specialty?  Well, we don’t really know because he managed not ever to actually talk about it, in spite of Alice’s passing interest.  Oh, sure, he told her that he had a specialty.  But think of that really more as a competitive advantage.

So what is Bob’s actual specialty?  Well, let’s assign him one.

I make huge portions of stick-to-your-ribs meat dishes for an affordable price in an otherwise expensive neighborhood in New Orleans.  If you like barbecue and oven-roasted meat dishes, you’ll find a flavor here you can’t find anywhere else, and you’ll go home stuffed.

Now, if you’ll excuse how much it would sound like a commercial, imagine Bob answering Alice’s question with that little spiel.  She would immediately know not only what he does, but also whether she’d like what he had to offer or not.  Bob’s value proposition would scream through this description of how he earns his living.

Where does the cedar plank shop talk fit in?  That’s Bob’s “secret sauce” (pun not intended) — his competitive advantage.  Bob solves a market problem (large portions of really good food inexpensively) by doing something novel.  For argument’s sake here, let’s say his work with cedar planks allows him to simulate flavor that would otherwise be more labor-intensive, and thus expensive to create.

NLP and Other Techs/Techniques are Metaphorical Cedar Planks

Let’s talk about natural language processing, specifically, since that’s the reader question.  But you can map your own “specialty” onto what I say here.  People have written me about all sorts of topics in the programming world as potential specialties: architecture, ORMs, database performance, block chain, etc.

You don’t go to a party, explain to someone that you specialize in natural language processing, and then hear them say, “oh, awesome, I could totally use some labor focused on natural language processing.”  There’s just no human alive who would say such a thing, even as nobody would say “oh, nice — I could use some cedar plank work!”

For NLP to be useful, you need a bunch of other people.  First, you need someone that comes up with a product or service offering that makes NLP a competitive advantage.  Then you need someone like a CTO that can mentally bridge the gap between the business problem and how a heavily technical competitive advantage solves that problem.  And, finally, you need some kind of project manager to navigate the day to day of making your competitive advantage useful and keeping you on track.

In short, picking a heavily technical and granular specialty helps you and your peers stake out territory that the wider world neither understands nor cares about.  And it tees you up to be an employee or contractor.  NLP isn’t a specialty in the way I’m talking about — it’s a competitive advantage to a business that someone other than you owns, runs, and strategizes about.

We’re Really Talking about Value Propositions

So to clear up confusion, I think it’s better that I start describing this not as a specialty, but a value proposition.  I cringe a little at that, since value prop is a very hand-wavy, consultant-y term.  But it also accurately conveys what I’m driving at.

In a nutshell, value proposition is a clear statement that:  (1) explains how your product solves customers’ problems or improves their situation (relevancy), (2) delivers specific benefits (quantified value), (3) tells the ideal customer why they should buy from you and not from the competition (unique differentiation).

I’ve often, in my writing here, condensed this to the shorter form of “I help [who] do [what].”  But the idea is the same.  Your specialty value proposition isn’t about you — it’s about the people you help.  When I go to the restaurant on the corner to get a huge plate of ribs, I don’t care whether the chef used cedar or not.  When I get annoyed that Alexa can’t understand me with a mouthful of ribs, I don’t care about the finer points of natural language processing.

You care about your competitive advantage so that your buyers don’t have to.

Building a Bussiness around NLP

Does this mean that that you should be a martyr and abandon doing work that interests you?  Should you identify a value prop and then deliver that value, however odious you find the work?  No, of course not.  Figuring out how to exist as a free agent or efficiencer (or even the right kind of salaried employee) is the art of discovering the intersection between some value proposition and your competitive advantage.

That’s messy stuff.

You’re going to have to iterate and brainstorm a whole lot before getting started.  And, as you go, both your value prop and your competitive advantage will necessarily evolve.  This isn’t easy — but it’s crucial.

And that makes it hard to offer a specific blueprint.  I can offer some answers to the questions in the broader reader question.

  • Is NLP too general?  As a competitive advantage, it’ll probably serve you well.  As a value proposition, it’s certainly not too general — it’s way too specific and technical.
  • Is some branch of NLP a good value prop?  No, that’s worse.
  • Should you focus on a vertical, like real estate?  Definitely getting warmer!

Aside from the framework of this post, I don’t know how to advise on specifics.  You could focus on a particular vertical.  This is a process known as market segmentation, and it’s closely tied with your value proposition.  But you could also focus on, say, building products or SaaS and offering a consumer application.  You can match a lot of value props to your competitive advantage and vice versa.

Taking Helpful Next Steps

I’ll close by offering advice — not so much on which value prop to pick, but on how to pick one.  First, do some market research and start to learn a lot about the different sorts of business problems that NLP solves.  Learn about the people for whom it solves these problems.  As you do that, you may find that not only does NLP appeal to you, but so does some particular vertical or general consumer of the technology.

From there, you can start to conduct informal interviews with people to see what solutions exist and also what gaps exist.  Are there companies using NLP in some way where they fail to take full advantage?  Or are there companies not using it at all that could really benefit?  Go lurk on NLP project forums and see what feature requests come up that nobody seems to implement.

This style of research will let you learn more about your prospective competitive advantage and toolbox, while giving you ideas for value propositions.  The more research you do, the longer your list of potential offerings will grow, and the more intersection points you’ll find between doing what interests you and scratching real itches that others have and will pay for.

It is indeed an organic and evolutionary process.  But it’s important to be very deliberate about setting up the framework to to engage that process.

By

DaedTech Digest: Test Smells, Monitoring, Performance, Spell Check

Hello, everybody.  It’s yet another week in my life where I successfully keep track of the normal work week without losing track of which days are the weekend and which aren’t.  To celebrate, here’s another DaedTech Digest Friday post.

And, lest you think that I lose track of days of the week due to a life of intense leisure, I can assure you otherwise.  We’re busily building Hit Subscribe, expanding our client base, our operations and our authorship.  We’re calling specialists and aspiring specialists to help us with paid post writing.  Drop me a line if you’re interested, either in writing or just in becoming a specialist.  I’m getting more serious about building some courses for aspiring free agents.

But that aside, let’s get to this week’s picks.

Picks

  • Last week, I accidentally crushed my phone, and today, I have a brand new one, despite being on the road without access to mail or normal logistics.  I’d like to pick Sprint for making that happen and generally being good from start to almost-finish.  I say “almost” because the phone activation process and their dial in menu was broken enough to prompt this rage tweet before I calmed down.  But everything else about the process was great.  Honestly.

  • The plugin I use to look at search volume, Keyword Keg, added a new feature that’s really cool.  “Analyze this page” shows you every imaginable keyword on a given web page, along with volume and competition.  Give it a look.
  • In spite of Medium seeming to try to turn itself into some kind of paywall or something, I managed to read this piece about programmers getting qualified from doing other stuff.  I feel as though the author is an efficiencer in spirit.
  • If you know me well, you know that I plug Trello early and often.  In the last couple of weeks, a few people I introduced it to a while ago have casually dropped into conversation how integral it now is to their lives.

DaedTech Post Digest

Happy reading, and happy weekend to everybody.

By

Conference Speaking Isn’t Good for Your Career Until You Make it Good

I like watching developer talks, live and recorded.  For my money (or free, depending on the venue), it doesn’t get any better than listening to Bob Martin work his way into a talk on software design by talking first about astronomy.  He and so many other speakers are engaging, charismatic, and informative.

So we strive to be like them.  We should put our names out there, give talks, and build our brand.

The Benefits of Conference Speaking

“Build our brand” is a little wishy-washy, though, so let’s get specific.  How does speaking at conferences help you?  I have my own opinion on this, but I went out in search of others’ to see.  In broad strokes, here are some specific things that I saw.

  • Make yourself better at public speaking.  It’s like Toastmasters, but in your domain.
  • Speaking at conferences means attending conferences, and that helps you “network.”
  • Give back.  Do your part in advancement of the general cause of programming knowledge.
  • Teaching something is a great way to learn, so speaking at conferences forces you to up your game and improve your chops.

I found some blog posts on the subject offering specifics.  Scott Davis says, “the knowledge that I’ve gained from teaching workshops has been invaluable and I don’t believe that I would have been as successful with out it.”  Heidi Waterhouse says, among other things, “I also do it because I want to show up and be technical and expert and pink-haired in the world.”

That last statement, in particular, I think summarizes up the common speaker experience in the development world (though Heidi, herself, is apparently not a software developer, per se.)  Public speaking on a topic helps you acquire a lot of skills associated with speaking publicly about that topic.  And it helps you “show up in the world.”

What’s less clear is how, exactly, that benefits you in your career.

Getting Specific about Your Career and the Benefits

Now let me say something up front.  If you’re speaking at conferences for the love of the game or to generally become a better rounded person, then what I’m telling in the rest of the post will either be passive food for thought or else not entirely applicable.  For the rest of this post, I’m addressing people who are speaking at conferences to help their careers, with the idea of offering advice on how to make it help your career much more efficiently.

When listening to people tout the career benefits of conference speaking for software developers, it generally takes on this iconic form.

  1. Speak at conferences.
  2. ….
  3. Profit!

I mean, it doesn’t actually go that way.  People don’t actually say, verbatim, “you should speak at conferences and then stuff happens and then your career takes off!”  Instead, they just say that speaking at conferences is good for your career.

How so?  Well, it “builds your brand.”  Okay.  And what does “building your brand” do for you as a senior software engineer or a freelance app dev pro?  Ah, well, it’s about marketing yourself!  Better job opportunities.  Advancement.  You know, … profit!

But let’s look at what, exactly, we’re saying will arise out of conference speaking.  And also what, exactly, people put into it.

Read More

By

Hacking Your Career as a Non-Developer

It’s Monday again, which means another Reader Question Monday.  This week, rather than renew my assault on all things sacred to software developers, why don’t I mount an assault on the design profession?

I’m kidding about the assault part.  Probably.  But today’s question comes from a designer.  I consider this cool because we knowledge workers should band together and because I’m glad that people beyond software developers read the blog and my book.

Here’s the question.

Loving Developer Hegemony – tons to think about.  I would love your thoughts on this situation.

I’ve applied for a green card, but that means I’m unable to leave my current, underpaid job.  I’m also stuck with the ‘designer’ branding through the eyes of execs, and the CTO (owner), who I report to.

What’s the best use of my time?

Inspired by your book I’d like to at least experiment with distancing myself from line-level design work, but I also don’t want to over-work, as my current deal is economically terrible, and I’m obviously an unlikely candidate for promotion.  Is it a matter of smartly deferring loser-work and snapping up, or inventing the ‘best’ projects for me, while cultivating my external network and side projects?

I’ve been pushing your book on the devs I work with – but most of them are too idealistic!!

First of all, thanks for your support buying the book, for reading the blog, and for your question.  Let’s get you some answers.

Examining and Inferring the Nature of Your Organization

First of all, a few things about this scream small-ish, perhaps not super-mature startup type of shop.  Why do I say this?

  1. Executives are interested in what (no offense) some line-level designer is doing.
  2. You regard the CTO as an “owner” rather than a shareholder or even co-founder.
  3. You’re underpaid.
  4. You report to the CTO.

Of course, the operation can’t be too rinky-dink, which I infer from the following.

  1. You say devs, plural.
  2. You have a staff role as a designer instead of a part time/freelance deal.
  3. They’re sponsoring foreign workers.

Why do I mention all of this?  Well, it’s good to establish some axiomatic context for the readership.  But it’s also important to paint a picture related to the corporate hierarchy that I so frequently reference, both in the book and on the blog.

You are, quite probably, in a company with an anemic idealist buffer between pragmatists like yourself, and the controlling opportunists.

Read More

By

DaedTech Digest: Analysis Rules, Singletons, and Log Aggregation

Happy Friday, DaedTech readers!  Time for yet another installment of the DaedTech Digest.

I didn’t do one last week because of the US holiday.  For those of you not from the US, there’s this holiday called Black Friday that everybody celebrates by getting together and eating turkey the day before and then subsequently bludgeoning one another in retail stores the next day.  Out of respect to this noble tradition, I held off on making a post.

At any rate, it’s been a busy couple of weeks in my world.  We’ve migrated south for about 5 weeks and are living in a beach town on the Gulf of Mexico.  This photo below is a shot of where I’m working from today as I type this post.

So life is good.  With that in mind, let’s get to picks.

Picks

  • The jury isn’t totally back yet on this, but we’re trying out FreshBooks for managing Hit Subscribe‘s books.  And, so far, it’s great.  And it integrates with other favorite Gusto besides.
  • I’ve been listening to an Audiobook called How to Measure Anything, and enjoying it.  Any consultant worth his or her salt spends a lot of time figuring out how to quantify problems and solutions, and this is definitely helpful.
  • The folks at a site called Data Camp reached out to me about the study I’m doing over at the NDepend blog.  They seem to be developing a cool offering for teaching people about data science using Python and R.
  • I also pick time off.  I work very much on my own schedule and generally not full 8 hour days anymore.  But I also do tend to work 7 days a week.  Last weekend, Amanda and I played tourist and did nothing but explore the Gulf Coast, buy fresh seafood off of piers, dine out, explore new cities, and walk through state parks.  This was nicely restorative.

DaedTech Post Digest

  • In my consulting (and even long-ago salaried) travels, I’ve encountered a lot of myths about code reviews.  I wrote a post for the SubMain blog in which I looked at some of those.
  • I wrote a post for NDepend, in which I explored a topic probably not many have.  What’s the role of static analysis in your testing?   These things might seem orthogonal, but I think they actually have an interesting relationship.
  • Also for SubMain, I did a post in the CodeIt.Right Rules Explained series.  I examined why you should avoid single line if statements, why you shouldn’t base your enums on weird underlying types, and the problem with explicit rethrows.  All of this in C#, BTW.
  • In a post that went a little viral and predictably resulted in people calling me a know-nothing incompetent, I wrote about what the singleton design pattern costs you.  This was for the NDepend blog, again.  (But I’d have the last laugh later, when I would actually study it empirically and prove myself mostly right — stay tuned for that in a future digest.)
  • In a much less controversial post (because they don’t enable comments), I made the business case for unit testing on the ASPE blog.
  • For Scalyr, I wrote a post about log aggregation.  What is this, why would you want it, and how does it help you?

And, that does it for the digest round up.  Have a great weekend!