The new C++ standard

I spotted on Esther Schindler’s Twitter feed a link to the Dr. Dobb’s article on the new C++ 14 standard.

This is exciting for me. I really like C++, even though I hardly ever get to use it. It’s a super-sharp power tool that simply isn’t as useful as C# in the database-heavy applications I usually work on. I have a lot of nostalgia wrapped up in C++. I remember running across the Stroustrup book in the public library (of all places!) and being fascinated by the concept and implementation of object orientation.

Sure, a lot of people would say that ruined me, because C++ is far from a purist’s language, but in its era C++ offered a pragmatic solution to a great many typical development challenges.

What’s new in C++

First of all, you know how you can use that var declaration in C# when it was too inconvenient (or at times impossible) to specify the type of a variable? You can do that in C++ 14 and you can specify the return type of a method the same way!

There’s a new [[deprecated]] attribute. It doesn’t break any code, it just kicks out a warning when you try to call anything that you’ve flagged as deprecated. Good way to soften the transition away from an API or implementation.

Syntactic sugar: You can now have digit separators in constants. You can write a million now as 1,000,000 if you want.

Generic lambdas with auto type parameters! That’s kind of esoteric, but the point is being able to declare lambdas that will figure out for themselves at compile time what argument types they need. It makes them more reusable.

Conclusion

C++ is still vital. It’s changing and getting better. I like it. I wish I could use it more.

Perils of “contracting”

“I haven’t had a real job since 1996.”

That’s what I keep telling people, and that’s largely true. If by having a real job you mean a salary, a long-term connection to a single employer, and company-paid benefits, then no, I haven’t had a real job in that long.

Honestly though, a lot of what I’ve been doing at work in those 18 years has been largely indistinguishable from having a real job.

Much of the time it’s easier and more profitable for me to work with those third-party contracting firms. They take care of a tremendous amount of the work that goes into getting work, and the good ones take a fairly reasonable cut off the top. (Typically it’s 25%, which sounds like a lot but have you seen how much staffing firms in other industries take?) What’s nice about this for me is that these firms have existing staffing contracts, functioning accounts receivable and payable, and a steady flow of open work requisitions. Most of the time, when I’m nearly done with a major project at one client, the same contracting firm goes through its existing client list, finds an open requisition that matches my skills, sets up an interview with the hiring manager, and has me checking in on the very next work day.

When all I care about is remaining “billable,” this is a good system. There are a few downsides though.

Requisitions are pigeonholes.

They are looking for programmers, QA people, project managers, and system administrators. They are looking for these people in either .NET or Open Source flavors. Add one category for network administrators, who seem to be allocated on a platform-neutral basis. (I don’t really know; it’s not my area.) That makes four times two plus one equals nine actual jobs that exist in the world of third-party corporate contracting. There are no coaches, no problem solvers, no interdisciplinary people, no jacks-of-trades. If your background makes you really good at seeing why their waterfall is blocking or at picking out why QA keeps having to look at the same defects over and over again, that job description doesn’t exist to them. So you have to decide which one of those nine things is you, and go with that, even if it’s an oversimplification of what you’re capable of.

Contract-to-hire is a scam.

Another downside, to some of us, is that creepy, weird “contract-to-hire” status. A lot of companies bring on technical people, on a contract basis, with something like a “right to hire” clause in the contract. I’m not clear on what this means exactly, because I don’t even consider those things, but it sounds like they’re asking you to accept a job they haven’t even offered yet. That sounds like a terrible deal. I’m supposed to sign a contract that locks me into a salaried (implied somewhat permanent) job when I’m not clear on what the job is, what it pays, and what the benefits are? What the hell is that about?

I don’t do “contract-to-hire.” It’s designed to put the worker at a disadvantage. Why would I want that?

Sigh, management

Yet another downside came up for me a while back, when I was about halfway through a six-month contract gig doing .NET development. It was going pretty well. I felt like I could have caught on faster to how the client’s ancient version control system worked, and it was clear that they were having some trouble allocating people to their three or four Scrum teams, but I did get to help a lot with a new product launch. My handler at the contracting company called me now and then just to say he was hearing good things about my work.

At one point though, I emailed my team manager (who supervises maybe about two dozen people) to let him know I would have to take an unknown amount of unpaid time off, specifically saying “my partner Jamie”–I used those words–was having gall bladder problems and there would be some hospital time. That week I missed a day and a half. My handler called the following Monday to ask why my timesheet read 28 hours rather than 40, and I told him. You would think that would be good enough, right?

That week I also billed 28 hours with another day and a half off of hospital time. It did turn out to be more than your typical gall bladder issue. Keep in mind that I was always keeping the team manager updated.

This place does three-week Scrum sprints, so missing three whole days is somewhat significant, and I had to scramble a great deal to come fairly close to fulfilling my share of the sprint. (That’s another issue: Scrum is a team commitment. We’re supposed to compensate when someone falters. That’s the idea.) Those three weeks were ugly. My personal burn-down chart looked like a jagged sine wave. But it did hit bottom in the end.

Speaking of hitting bottom,

after that, it wasn’t remotely the same. Even though my role going in was clearly to stick with .NET middleware development because I’m not good at front ends and browser scripting, I got handed a lot of browser scripting defects. (Again: not so great Scrum, right?) Planning meetings for the next big project were carried out in my absence. Standup meetings even got a little hostile. One of my handlers called to criticize me for having a personal life, with some reference to not deserving unpaid time off. It was weird.

What Jamie said after all this:

“Next time, just say it’s your wife.”

All I can figure…

…is that in this shop, they feel that a person who’s willing to work on a contract basis should be so grateful for the opportunity that we should drop absolutely everything else, including family and loved ones, for the opportunity to be micromanaged and disrespected. And pretend to be straight while we’re at it.

I chose to finish the six-month engagement quietly before taking a nice vacation. And if that particular staffing company ever wants that 25% of my billing rate again, we’re going to have a rather direct conversation about who gets to have an opinion about their sense of entitlement to my personal life.

So I don’t do that.

Here’s how it goes. I do a lot of straight-up freelance work–custom application development, coaching, training, and team leadership–directly for all kinds of businesses and organizations. Doing my own marketing and business development is actually a huge amount of work, and it gives me all kinds of respect for the people who do that all the time, but it’s still my job so it doesn’t feel like a distraction.

In fact, what I learned from gurus like “Original Mark” Silver and Robert Middleton is that marketing is inseparable from products and services. Part of delivering great work is letting people know it’s available. Part of publicizing what you do is the act of doing it. It’s actually not realistic to say “I only write code, I don’t do sales and marketing.” You’re doing it whether you know it or not. Whether you like it or not.

Thanks but no thanks

So when the rent-a-geek firms call, and they will, I think I’ll start referring them back to this blog post and thank them for their interest. I like having tons of billable hours handed to me, but at this point the attached strings aren’t worth it.

Don’t have coding standards

I’m doing a new thing now!

If you’re currently on my eZine and announcements opt-in list–and you should be, because it’s usually not boring–you found out about it this morning.

Long story short, and not to kill the suspense, the main thing is that if you send me some problematic C# code, along with a very reasonable amount of money, I will turn around a solid code review, complete with prose narrative, suggestions, and maybe even bug fixes. (I’ll put all the details up next week, but that’s next week’s problem. You should be on the opt-in list!)

One thing I won’t do, though, is impose “coding standards.” I don’t think you should have them.

Why you shouldn’t have “coding standards”

Okay, that’s actually wrong. I do think you should have coding standards, even if you work by yourself as a lot of my fans do. Have a regular, standardized way of naming things. Of indenting. Of when to break something into more than one class. Of when to unroll loops.

Sure. There’s nothing wrong with that if it makes you feel better.

The benefit of having standards is that you don’t have to think about them. That’s why I’m saying… don’t have them.

Here’s what I really mean.

Again I’m going to play the “I’ve worked in sixty development shops” card. I’ve seen a lot of single developers, startups, growing concerns, flailing concerns, and mega-corporations do software development to a WIDE range of success. And pretty much always, someone senior at some point calls a meeting and says…

…Let’s Have Standards.

In practice, that means you spend a few hours in more meetings going over the oh-so-important issue of whether to name your classes in camelCase or PascalCase. Where the curly brackets go. You know, all that stuff that ReSharper already does for you.

I’m saying those meetings are not a productive use of time. Your deliverable becomes a set of rules that everyone either has to try hard to remember, or rules that nobody bothers to follow at all. And I keep asking, what is the problem you are trying to solve here? Nobody’s totally clear on that.

  • If your architecture is too complicated, reduce the architecture.
  • If you lack unit tests, build code with unit tests.
  • If your code is too tightly coupled, think about where the seams should go.
  • If it’s hard to find the class you want, pick better class names.
  • If you have a lot of duplicated code, refactor it to remove the duplication.
  • If your problem is excessive defects, then “standards” aren’t going to help at all.

So either you think about these rules and they get in your way, or you don’t follow them and they don’t help you. In any event, they don’t solve any actual known problem. Come on, when was the last time you honestly couldn’t get something to work because the curly braces were in the wrong place? Ever?

Here. Let’s make it easy.

Why not save everyone some time and annoyance and just use ReSharper? You can leave the default ruleset, which is a pretty reasonable one, or customize it if you really really want to, but the important thing is to set it up and not worry about ever again.

The main thing is to know what the problem is that you are trying to solve instead of getting excited about a solution that may not help you at all.

I’ve found that the shops that take more than about fifteen minutes, ever, to discuss “coding standards” are the ones with pretty severe process issues that “standards” won’t at all fix. The right path is directly to the source of those problems, not one of avoidance.

 

Change observation, not change control

A while ago I posted about Baqbeat, an enterprise systems management tool being developed by my college homie Dave. A lot of things have changed since then.

For one thing, the name has been updated to the less quirky but more descriptive “Congruence.” For another thing, the code is actually getting done. And, as we were discussing the other day, the minimum usable product concept has been pretty well refined.

Why this thing even matters

In a recent Facebook chat, Dave put it this way:

That is my real, underlying motivation… cutting back on the bickering and finger-pointing! It starts with replacing “But we didn’t change anything!” with “What changed when?” and getting a computed rather than human answer.

Then I ran into John, who runs a pretty substantial outsourced data center, at my favorite coffee joint in Lakewood and talked his ear off for an hour and a half. The thing he picked up on was the distinction between change control, which everyone wants to do but nobody has figured out, and change observation, which is actually feasible. I think it was John who said that trying impose a global solution to maintain all the database structures, configuration files, source code releases, and other knicknacks in your big corporate setting is “boiling the ocean.” He’s right. Strategically, you can try to control everything–which becomes a huge top-down endeavor that depends on someone making a big decision and making scores of underlings follow through–or you can take the gentler approach of watching what does change, and correlating it when something goes wrong.

I could go on for a while about the Congruence architecture that supports all this monitoring and correlation, but the cool part for me is that it has Agents and Minions and Dave doesn’t know very much about .NET. So in a couple months you may see me coding a base Congruence Agent for .NET.

For another perspective, Dave summarized his “aha! moment” on this point about observation.

What you can (and should) do now

If you have anything to do with changing or managing stuff in a network that has more than about three computers, go to the pretty placeholder site for Congruence right now and get yourself on the email notification list.

Start thinking about things in your network that change and break stuff. Think about how much it will help to have something that just lets you know what changed.

Get ready for a fall pre-beta thing.