DaedTech

Stories about Software

By

How to Freelance: The Low-Risk Path from Software Developer

Ah, the eternal opportunistic question: how to freelance?  You work as a software developer, making $100K per year or something.  This is a great wage, and so you have a great life, sitting pretty high up atop Maslow’s famed hierarchy.  But then you figure out that Steve in your group is actually a contractor, and a little later, you figure out that they pay Steve $70 per hour.  A quick google search for “work hours per year” and fast math tell you that Steve makes $145,600 per year (so you think, anyway).  Suddenly, you feel less like a prosperous citizen and more like a sucker.

How to Freelance like Steve and make big money

How can I get some of that Steve money?

Not far behind that thought comes another.  I should become a contractor!  And then, finally, we get back to the titular concern: how to freelance?

The Reader Question and Some Housekeeping

As regular readers may have deduced, I’m doing a reader question today.  And, as regular readers may have noticed, I haven’t done reader questions (or DaedTech-only posts) in a while.  Please forgive me on that count.  I spent a lot of writing energy on my recent book launch and then even more on starting a tech company blogging business.  With all of that writing, I’ve had trouble mustering spare writing cycles the last few weeks.

But I’m turning a corner on that and launching the first of what will be a series: “reader question Fridays.”  I’m making the vision of this site more and more oriented around the Developer Hegemony vision (software developers becoming the bosses of software development), so please fire away with questions.  I take all comers, but I’ll prioritize questions that speak to the subject of software developer agency.

Anyway, I’ll paraphrase the reader question.

I currently work as a salaried software developer.  I think I’d like to figure out the freelance thing, but I’m not sure.  It’d mean a lot of risk to quit my job and hang out my shingle, so I’m wondering what you advise to make this a less risky transition.

I actually wrote about a related topic recently.  But that question more concerned my personal background and how to become a consultant.  Freelance software development is not, in my opinion, consulting.  I refer to people who do that as software pros.  Firms pay consultants for their opinions and they pay software pros for their labor.  I draw the distinction here because software pros need to worry a lot less about specializing and niching — at least at first.

But forget about the taxonomy and let’s look at how to become a freelance software developer with a low risk playbook.

Read More

By

The Most Commonly Reinvented Wheels in Software

Editorial note: I originally wrote this post for the Telerik blog.  You can check out the original here, at their site.  While you’re there, take a look at their developer tools and controls offerings — they’re quite extensive.

If you ever want to set off a heated argument among software developers, you could do worse than to ask about “build vs buy.”  This one touches the third rail to such an extent that it has many colloquial names attached to it.

If you want to see this debate in action, plenty of venues exist.  Developers may accuse one another of reinventing the wheel, only to hear that some wheels need reinventing for various reasons.  Opponents of the practice have even described it as a syndrome, called “not invented here syndrome.”  But I have also seen proponents turn the tables and call out “not ever invented here syndrome” to describe software shops that awkwardly buy when building makes more sense.

Suffice it to say opinions abound and no clear consensus exists.  The highly context-specific nature of a given example also muddies the waters.  What makes sense for your team in your situation may not apply to another team.

I’ve offered thoughts on navigating this issue in another post.  Today, I’d like to avoid controversy.  I won’t weigh in on whether reinventing wheels makes sense because it deepens your knowledge or whether it wastes time and money.  Instead, I’m just going to catalog the most frequent examples I see of wheel reinvention.  As a consultant that specializes in assessing codebases and application portfolios, I see a lot of code.  This gives me a bird’s eye view of what shops love to write themselves.

Read More

By

Detecting Performance Bottlenecks with NDepend

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, take a look at NDepend and see what it can tell you about your code.

In the past, I’ve talked about the nature of static code analysis.  Specifically, static analysis involves analyzing programs’ source code without actually executing them.  Contrast this with runtime analysis, which offers observations of runtime behavior, via introspection or other means.

This creates an interesting dynamic regarding the idea of detecting performance issues with static analysis.  This is because performance is inherently a runtime concern.  Static analysis tends to do its best, most direct work with source code considerations.  It requires a more indirect route to predict runtime issues.

For example, consider something simple.

public void DoSomething(SomeService theService)
{
    theService.DoYourThing();
}

With a static analyzer, we can easily look at this method and say, “you’re dereferencing ‘theService’ without a null check.”  However, it gets a lot harder to talk definitively about runtime behavior.  Will this method ever generate an exception?  We can’t know that with only the information present.  Maybe the only call to this in the entire codebase happens right after instantiating a service.  Maybe no one ever calls it.

Today, I’d like to talk about using NDepend to sniff out possible performance issues.  But my use of possible carries significant weight because definitive gets difficult.  You can use NDepend to inform reasoning about your code’s performance, but you should do so with an eye to probabilities.

That said, how can you you use NDepend to identify possible performance woes in your code?  Let’s take a look at some ideas.

Read More

By

Developer Hegemony in More Bookstores

A few weeks ago, I officially launched my book, Developer Hegemony, on Amazon.  It went well!  For a while, the book was the #3 best seller in the “workplace” category.  It has, not surprisingly, cooled off since launch week, but it continues to sell in both bookstores (Amazon and Leanpub).

Many people asked me about launching the book in other stores and via other media.  Most commonly, I fielded requests about iTunes and an audio book.  Well, I would still like to do the audio book, but I’m not planning anything for that in the immediate term.  On the other hand, I can deliver on iTunes and some others besides.

You can now purchase Developer Hegemony in the following other bookstores.

So for any of you that have waited for this release, I’m pleased to announce that you can now get the book.  And, of course, you can continue to purchase it on Amazon.  In fact, if you want a paperback copy, Amazon is the only store that provides that option.

Developer Hegemony Beyond the Bookstores

I find it interesting to have the book out there in bookstores.  I wrote it on Leanpub and it occupied evenings and weekends for a couple of years.  And, while I finished writing it some months ago, the pre-launch preparation consumed my spring.  I’ve lived with the book as a huge part of my life, and now it’s done and out there in the wild.

I find that satisfying, and I enjoy the accomplishment.  But I don’t just want to leave it there and call it a day.

So I’m thinking about what I can do to help further the vision in the book.  And, over the coming months and years, I plan to produce related content at the very least.  I did create a Developer Hegemony Facebook group, and I welcome you to join that and offer feedback or discussion points for what sort of content you’d like to see.

Upcoming Content

What kind of content?  Well, I’m going to start reasonably small and take it from there.

My wife and I have started a business helping developer tools and training companies with content tech marketing (i.e. blogging).  As we set that business up, I’ve started recording video of what I do in the hopes that it will help others.  How do you incorporate?  How do you get an EIN?  That kind of thing.

So as we get business operations going in earnest, look for that type of content on my Youtube channel.  From there, I may start formalizing some of that into lessons available for purchase in some format.  But I want to figure out and confirm the value proposition before trying to sell anyone.  All of this falls under the general heading of helping software developers become the people in charge of the software development industry.

And as for other books, I’d definitely say to stay tuned for that.  I have an itch for writing books now, and I think it’ll be hard to keep me from doing more of it in the future.  I’m not sure just what I’ll cover yet or when, but I do continue to enjoy writing.  And I hope that all of you continue to enjoy reading.  As always, I thank you for all of the support.

By

Make Alerting Apps Work for You

Editorial Note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, take a look at the monitoring solutions and integrations they have to offer.

Some years back, I worked as the CIO.  During my tenure, I had a head of IT support reporting to me.  He did his job quite well and had a commendable sense of duty and responsibility, and I will always think of him as a model employee.

I recall an oddly frustrating conversation that I had with him once, however.  He struggled to explain what I needed to know, and I struggled to get him to understand the information I needed.

Long story short, he wanted me to sign off on switching data centers to a more expensive vendor.  Trouble was, this switch would have put us over budget, so I would have found myself explaining this to the CFO at the next executive meeting.  I needed something to justify the request, and that was what I sought.

I kept asking him to make a business case for the switch, and he kept talking about best practices, SLAs, uptime, and other bits of shop.  Eventually, I framed it almost as a mad lib.  If we don’t make this change, the odds of a significant outage that costs us $_____ will increase by _____%.  In that case, we stand to recoup this investment in _____ months.   In the end, he understood.  He built the business case, I took it to the executive meeting, and we made the improvements.

As much as we might like it, people in technical leadership position often cannot get into the weeds when talking shop.  If this seems off-putting, to techies, I’d say think of it this way.  Techies hack tools, code, and infrastructure, while managers and leaders hack the business.

Read More