There are few indications of how broken an office communications culture is than emails titled “PLEASE STOP AND READ THIS MESSAGE.” There was a time when Email was to office communications as Democracy was to government — “the worst… except for all the others.”
That’s not true anymore. There are better ways to communicate, collaborate, and work together. Choosing good ones and encouraging the adoption of them can really change the character and nature of your work-place. Give it a try.
Like many Americans, I watched the Presidential Debate last night. I could spend pages on what was said and not said by both candidates but one line from Secretary Clinton really stood out to me as a technology professional in the field of Cyber Security.
“We need to make it very clear — whether it’s Russia, China, Iran or anybody else — the United States has much greater capacity. And we are not going to sit idly by and permit state actors to go after our information, our private-sector information or our public-sector information.” (more…)
I’ve been doing front-line software development for more than a decade now. I got my first job in the industry working for this small startup making the digital equivalent of a calendar or a fruit-basket for real estate agents to give out to their clients. The business side of the enterprise seemed so far away then; the rest of the team and I put our heads down, banged out features, solved problems, and were shocked to find, three years later, that the product we’d so lovingly crafted wasn’t selling because our target market didn’t have money to buy it.
Since then I’ve worked for the military and done battle with ColdFusion, a contract development shop where I tooled around with mobile before mobile was big, and another small company doing C# web development for the mortgage industry. As I’ve changed jobs my roles and responsibilities have drifted further and further away from head-down coding and towards more nebulous things like “architecture,” “process,” and “professional development.” (more…)
This is less of a blog post and more of a brief public service announcement. If you are using Entity Framework and you change the namespace of your Context file bad things will happen. Future Add-Migration commands will attempt to re-script your entire database. Google will be remarkably unhelpful in diagnosing this problem.
“But,” you say, in your best Comic-Book-Guy voice, “changing namespaces is annoying; no one would just change their Context’s namespace.” To which I reply, “if you’re using ReSharper you might, because it pretty much automates the process and nags you if you move files around.”
Not that solving that problem just consumed an hour of my day or anything.
One of my goals in spinning up a software development team at Foxguard has been to have a development environment ready to go before the first person comes through the door. That means a vague skeleton of the application we are developing as well as the apparatus of building, deploying, and testing that application. Since anything worth doing is worth doing right we’re approaching the latter problem with a Continuous Deployment solution in mind. That means that every time we commit code it is picked up by a automated script, built, tested, and published — ready to begin evaluation through some as-yet-to-be-determined test suite.
The first part of this is fairly easy. Jenkins is a great tool and there is no shortage of tutorials out there on how to make it play nicely with GitHub, MSBuild, or any other technologies you might be using.
Deployment, though, is a bit of an more difficult nut to crack. (more…)
Thus is the danger of over-automating your life. I long-ago configured
So now we’re back up and running with a new and improved spam filter.
Software development is about process refinement. Try something, see if it works, revise, adapt, reset, and try again. If you’re doing the same thing the same way every time you’re not moving forward and, in this field, that means you’re falling behind. Do that long enough and you start to apply it to other things in your life. I switched from a QWERTY layout to Dvorak for more or less that reason (working out well, by the way) and I’ve taken up baking and gotten into coffee with much the same approach. (more…)
After a lot of soul searching on my professional future and the path that I want that future to take I have left VirPack and, today, begin my new adventure at Foxguard.
Here I will have the opportunity to build and likely manage a development team, the freedom to build quality and maintainability into the software process from day-one, and an opportunity to really make a difference in an industry in flux.
On the down side, I no longer have a window in my office.
Deep breath; here we go!
Back in the 1940s a guy named Dvorak got it into his head that the way we type is wrong. Our fingers transit too far across the keyboard, he argued, and as a result our motions are inefficient and slow. Dvorak rearranged the standard QWERTY keyboard to make typing more efficient, eliminating the design constraints which had originally informed the layout we all learned to type on.
In theory, that should make for a faster typist though it does take some getting used to. For me, this marks the jumping off point and possibly a painful transition. This entire post was touch typed using the Dvorak layout and, despite quite a bit of practice on a
One of the projects I have been working on with VirPack has been the establishment of a developer’s training program and central to that program has been Robert Martin’s materials on Clean Code. While many of Martin’s ideas have sparked some interesting discussions at VirPack, none has been more controversial than his discussion of Test Driven Development. Martin holds to a three-part cycle: Fail, Pass, Re-factor – in which you write just enough of a test to fail, just enough code to pass, and sometimes re-factor to clean up before cycling back to failure. This results in a number of areas, particularly in Martin’s examples, where tests seem to be written merely to justify an action everyone agreed was necessary in the first place — say, a test to see if you can construct an object which is then run, and fails, because the object does not yet exist.
While I am pretty well sold on Martin’s coding philosophy I decided to take my coworkers objections under advisement but with a grain of salt. Most of the Kata and examples that Martin works through are very simple; they have to be in order to be short enough and accessible enough to communicate the points he is trying to make about software development but that simplicity also means that the early fixed-costs of TDD seem very big compared to the actual “meat” of the problem he is trying to solve.
So I set out to try out true TDD on a project which I knew was going to be complicated. Martin’s examples of things like a bowling score calculator had just a few plausible test cases and a mere handful of interesting results which could emerge from a complete examination of all possible execution paths. I wanted something much bigger and much more complicated and the historian in me knew just where to look. (more…)