Sunday, October 5, 2014

Finding Time to Compose

Over the past year I've been building TeamworkHub. Before that it was something else, and before that another thing. All the way back to when I was a kid building things with an erector set and whatever broken appliance and electronic parts I could confiscate from my parents. I guess I've always been building something.

It's easy to get caught up in the trap of wishing I had more time to focus exclusively on building. "If I could just have 6 months to work exclusively on this, I'm sure I could [make millions, paint the Mona Lisa, write that Piano Sonata]!" But, there are bills to pay, fun to be had, and demands on our time each day. Often the things we are building aren't what pay the bills (at least not at first!) We are left to our own desires and motivations to find time to build stuff.

The ironic (and awesome!) thing I've learned is that having long stretches of uninterrupted devoted time isn't always the most productive way to build something. Often, smaller blocks of planned time to build can actually be more productive!

When I do manage to have large chunks of uninterrupted time my mind tends to focus less. "Ah, all this time to work. Finally! Let me pick just the right music to play for this grand occasion! I'll find my comfy coding hoodie, brew some coffee, …." and before I know it I've eaten up most of the day embracing my time to code, but getting very little done.

I find that short bursts of planned work, with time to reflect afterwards can actually be the the most productive for me. I don't like to think thats the case. I like to think if I had those large chunks of time I could get more done. But a lot of my "aha" moments seem to come subconsciously when doing something else after short bursts of focused work. The brain can be pretty strange about that.

Sure there are exceptions. Sometimes you get into the zone and are cranking away, and another few hours would be really productive. But you can't always force those things to happen on the day you have a large chunk of time available. They happen when they happen. You embrace them when they do happen. Maybe go to work or bed an hour late while you run with an idea. But just because you have a large chuck of time available doesn't mean you'll be able to get into the zone.

A few months back I was reading Daily Rituals: How Artists Work. I came across a passage from a letter that Mozart wrote to his sister shortly after moving off on his own to Vienna to be a freelance composer and performer. Mozart wrote to his sister that he could only find a couple of hours a day to compose, usually between 7 and 9 AM.

From around 9am to 1pm Mozart taught piano lessons to pay the bills. From 1pm until late in the evening he socialized at whatever event he could get an invitation to in order to schmooze and get his name around while looking for composing and performing work. He would sometimes compose again for a couple of hours in the evening around 9pm, but often after wining and dining he couldn't get back to composing.

This is Mozart. Mozart! And even he wasn't able to always dedicate all his time to composing, but had to pay bills and do other things like the rest of us at various points in his life.

Don't let the current circumstances of  the day prevent you from carving out your time to do your calling work. Find an hour or two a day to build something, write something, work on something, or learn something.

Embrace your time to compose in the hour or two that you have.

Monday, July 14, 2014

Introducing TeamworkHub

TeamworkHub is a workplace team collaboration and productivity application perfect for self-organized, cross-functional and remote teams.

I've had the pleasure to consult, contract, and work for quite a few companies over the years; everything from small businesses to large enterprise organizations. One consistent thing I've discovered along the way is the need for better team collaboration and knowledge sharing.

I've seen multiple "Welcome to the team" processes that involved an email packet with 100's of attachments. I've been in status meetings where people go around a table giving status updates to work item numbers! How much collaboration comes from the employee next to you saying they are 25% done on item #123?

What tools do you use to promote teamwork at your organization? Do these tools promote collaboration? Do they promote knowledge sharing? I think you are missing out on a lot of team productivity if email and status meetings are the only real tools to your current teamwork solution.

There is software out there that tries to solve this problem, but outside of the tech community, I haven't seen it used at most organizations. Most of what is out there is either too complicated or misses the mark on what it takes to make your teams productive.

Earlier in my career I had the opportunity to be a member of very productive cross-functional team in a manufacturing and sales company. The team was made up of key players from each respective department; sales, manufacturing, marketing, information systems, and logistics. I represented the information systems department and organized the meetings.

The team was lifeblood to the success of the company. Everything from weekly promotions to major company reorganization were coordinated through this team. And we thrived for years.

I learned a lot in those days about what it takes to make a team successful and productive over the long haul. During my subsequent contracting and consulting career I've yet to come across many teams that have had the long term impact that team had on the success of that company. I know your teams can be more successful than they are today!

For years I've seen companies struggle to find ways to keep everyone productive, engaged and on the same page. At TeamworkHub we are working to change that. We are building an application with a sole purpose of sustainable team productivity. I welcome you to follow along with what we are building at the The TeamworkHub Blog.

If you are part of an organization that currently struggles with team productivity, I encourage you to take a look at and see what it can do for you.

As of this writing, the first 30 days at TeamworkHub are free, so there is no obligation on your part to pay for anything before you get a chance to try it out. If you decide that TeamworkHub can help your teams be successful then we have monthly cloud plans that range from small businesses to larger companies. We also offer tailored solutions for bigger enterprise organizations.

I hope TeamworkHub can help your teams be the sustainable lifeblood to your organization that I know they can be!

Happy Teamworking,

Accomplish More When Teams Work!

Friday, April 26, 2013

My thoughts on technical debt take 2

I did a bad job last week conveying my thoughts on technical deb. A friend that knows me well enough to have an idea of my opinion on the subject let me know that the post didn't sound like me. So, I'll take a minute to try and review what i was saying.

Technical debt as it was originally defined, can be a useful metaphor. My very limited knowledge of how Ward Cunningham originally presented it was that it was not a deep dissertation on the subject but just a little statement that started with "Shipping first time code is like going into debt." The idea being, all the little shortcuts you take to get first time code shipped are like debt, and in order to support and maintain that code going forward you will eventually need to pay that debt back; the sooner the better. If you don't pay that back, the codebase will become unmanageable and the cost of change going forward will keep going up.

Ok, fair enough. A little metaphor to help us be conscious of the cost associated with shortcuts and decisions we make early on in order to ship code faster. And a very good metaphor at that. To be fair though, the opposite end of the spectrum is filled with cute little metaphors and acronyms too; premature optimization, YAGNI (you aren't gonna need it), analysis paralyses, etc.

These metaphors can help us make decisions around things we do and don't do during the process of building and shiping working software. But, to complicate matters, on any given project you will have varying levels of developer experience and skills, and the answer to these questions won't always be the same. I'd probably go out on the limb to say even if you take a room full of developers with basically the same rating of skills they would make varying decisions along these same metaphor points.

Interestingly enough, in my previous post, I really wasn't talking about any of that. I was talking about something I'm calling "Technical Debt brouhaha". Which is more about the manifestation of the technical debt metaphor into something toxic.

When a term like Technical Debt becomes more then a metaphor used to help make decisions, and instead is used by developers of a codebase on a daily basis it can become toxic. When it becomes toxic, developers start using technical debt to mean:
This code sucks.
This isn't how I would have done it.
This code is too procedural.
This code is too object oriented.
Why are you using this gem, plugin, etc; thats a liability.
Why did you write that yourself instead of using this gem, plugin, etc.

Do you see where I'm going? There is a huge difference between using a metaphor to help make decisions, and instead just complaining about stuff. Often, once this toxicity starts it spreads like cancer, and soon every developer in a shop hates being there on a daily basis.

Sure we all have to let off steam. And some codebases and some environments really do suck. But as a professional software developer, you owe it to yourself, your client or your employer to do your part to try and leave the a code little better then you found it. Regardless of the reasons the code is the way it is.
I've been known to get in some pretty heated debates with other senior developers on a project. But its always because I believe what I'm fighting for will make things better. I try to keep that behind closed doors. And when I loose those battles, I come out and do my best to make the given path as good as possible. Debate can be healthy and good for a project. Complaining is toxic.

How about this. Instead of complaining about all the technical debt your codebase has, try to think of one little thing you can do to help make it better. Just one little thing you can do with this current commit that can help make this codebase just one tiny bit better then it was before this commit. Then think about something you can do to grow upon that. What makes this code so painful to work on that you just hate it? How can you at least abstract that pain, and then share that with the other developers? Soon you will laugh about it and say "why didn't we do this sooner"? Be the snowball that starts the avalanche of good, and not the toxicity of complaint.

Tuesday, April 2, 2013

my thoughts on technical debt

I'm calling bullshit on the "technical debt" brouhaha. Everywhere I turn I hear developers blabbering over technical debt. Developers crying about "repaying all this debt or we will be crippled.' Blah, blah, blah. Bullshit. 

Don't let the fear of technical debt stop you from building software that has business value. Ever. Its software. Its not steel and concrete. Software, is meant to be changed, modified, patched, and often thrown away. Yes, the results of some decisions will be more difficult to change then others, but it can all be changed.

Technical debt really only matters if your app is a success. And by success I mean that the app adds business value and has a reason to survive, be maintained, and grow. And by this definition, it is already a success.

Conversely, technical debt is forgiven and means nothing if your app ends up not serving a business need and has no reason to be maintained and grow. 

Every app has some technical debt. Most apps I work on have a lot of technical debt. Shortcuts, bad decisions, tightly coupled code, huge classes, little or no test. Often these decisions make my job hard and cause fixes and enhancements to take longer. But at the same time, I know that all these warts and problems are part of something greater. Something called shipped product. Something providing enough business value to someone somewhere that the app owners can afford to pay me to enhance them and make them better. And thats pretty special. 

I have hard drives full of pet projects and weekend work that was created in the spirit of minimal technical debt. But most of those projects are dead on the vine. Not because of their technical merit. But because they never got completed and shipped or didn't provide the business value I thought they would. Shipped code that is providing value to someone somewhere is a special thing. 

As professional software developers we go to conferences, read and write books on our craft, and constantly try to better our game. And all that is good and important. But none of that matters if there isn't shipped software providing value to people, and that is what matters most. 

I have seen more successful software in the wild providing business value that was written by people that just weren't that good at writing software, but figured out a way to ship and fulfill a business need, then I have pristinely written code. Its just fact. Warts and all, shipped code providing business value trumps pristine code sitting on a hard drive. 

So, lets help our clients or employers by making code better and easier to maintain. Because that is what professional software developers do. But lets rein in all the technical debt preaching, ranting and bullshit. It was a cute term for a day or two.

Build it. Learn from your mistakes. Make it better. Create value.

Wednesday, November 9, 2011

slim from a haml user's perspective

I've been a fan of haml since first taking a look at it in 2007. I use it almost exclusively on all my projects. Lately, I've been hearing more about slim and decided to have a look. Both template frameworks share similar goals of reducing the amount of html syntax so you can focus on your content and semantics without all the brackets, and open and close tag syntax getting in your way. Slim also claims some pretty impressive performance benchmarks.

Slim's 'about' page claims you can make it look more like haml by using id and class shortcuts, but that they are optional in slim. This struck me as a bit misleading, because regardless that haml id and class shortcuts are popular with haml users, they aren't necessary in haml either. They are a completely optional choice in haml as well.

There is a fundamental difference in how markup versus content is treated between the two frameworks. And, after working with slim for a few hours, I'm not sold on its syntax. Maybe its my years of familiarity with haml that is causing some friction.

Haml takes the approach that html elements start with a delimeter and then your content is free to be nested or included inline. This makes sense to me. If I was writing normal html, my elements would be delimited by brackets wrappers, and my content would flow within.

Slim, on the other hand, assumes that html elements are not delimited, but content is. I'm not being completely fair here because inline content is not actually marked up separately from being on the same line as an element tag. But, content either needs to be inline with an element tag, or marked up with a pipe or backtick.

From the slim documentation:

Add content to a tag

Either start on the same line as the tag

  h1 id="headline" Welcome to my site.

Or nest it. Note: Must use a pipe or a backtick to escape processing

  h1 id="headline"
    | Welcome to my site.

A similar example in haml, might look like:

  %h1(id="headline") Welcome to my site.


    Welcome to my site.

For me, the slim approach seems bass ackwards in this regard. Perhaps its just my familiarity with haml, but this fundamental difference kept nagging at me while I tried slim out for size.

Friday, September 23, 2011

installing ruby-debug19 with rbenv

Here is what worked for me. Obviously change path to work for you and your specific ruby version:

gem install ruby-debug19 -- --with-ruby-include="/Users/scott/.rbenv/versions/1.9.2-p290"

Monday, September 5, 2011

Rails 3.1 require_tree CSS

This is a post about a Rails 3.1 convention and choice used to assemble your application's CSS file. Its not a post about the general idea of the Rails 3.1 asset_pipeline, but assumes familiarity with that. I also offer a simple alternative that might be considered that isn't too far off from the default.

It's a trivial thing that I've griped about a few times, but the choice in Rails 3.1 to link to a application.css manifest file that includes a "require_tree ." directive off of the app/asset/stylesheet root is imho a stupid convention. For one thing, when building a CSS solution for an application, the order of the included CSS matters. And if all of these CSS files are assembled into a single application.css, the order of inclusions still matters. I realize that it is simply the default application.css, and it is very easy to delete the one line that says "require .". But if every real application will need to do this, then I think its a pretty stupid convention.

If your entire application's css file was only ever the assembly of some n controller_name.css files, then this would be a moot point, and the Rails default "require_tree ." would be fine. But I think its a fair statement to suggest that is fairly close to never the case.

I appreciate the idea of making things dead simple for people just getting started. And I get the fact that the default action of a controller generator is to create a controller_name.css.scss file. And I get the fact that this "require_tree ." by default provides a out of the box experience that stitches all these files together to create your application.css.

The problem is that seldom if ever in an application do you create a CSS solution that doesn't involve some hierarchy to its style rules. Often you will include some basic typography rules defined in one or more files, some basic layout rules in another, some basic color rules in yet another, etc. and then apply some hierarchy of granular changes on top of these as necessary. Even if you don't take a typography, layout, color approach to foundation, in any real application you will have some foundation rules, that are then refined in a cascading or granular fashion, where the order of these subsequent granular rules is important.

Additionally, in applications built today, you often have a different set of basic foundation rules applied for different reasons (different section of your application, different media, different browser, different resolution, etc.). In the Rails 3.1 asset approach, all of these styles will need to be defined at some point under app/assets/stylesheets. You would almost never want everything under your stylesheet root to always be included, and especially in a manner where order has no significance!

So, my basic gripe is that seldom (if ever!), will you have a situation that suggests assembling all css under your "root" css directory will make sense. And additionally, this will almost never be a best practice convention that anybody building a real application would be able to use. So, why does Rails 3.1 use this as its out of the box convention?

A fair alternative to the out of the box convention for Rails to follow might be to build all controller_name.css.scss files in a subdirectory off of app/assets/stylesheets, perhaps app/assets/stylesheets/resources (or controllers). And then the default convention in application.css might be to "require resources/." by default.

Then if Rails wanted to promote some additional best practices, they might include some top level foundation css (like typography, layout, color, etc.) or even just a base.css.sass that could be explicitly required in the application.css to give the new developer a convention that is at least built upon some real world best practices to creating CSS solutions.

A default asset pipeline application.css file that looks like this:

 * This is a manifest file that'll automatically include all the stylesheets available in the resources directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * immediately after your foundation styles, but it's generally better to create a new file per style scope.
 * Application foundation styles
 *= require 'typography'
 *= require 'layout'
 *=require 'color'
 * Specific styles
 *= require_self
 *= require_tree resources/.

or even just this:

 * This is a manifest file that'll automatically include all the stylesheets available in the resources directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * the top of the compiled file, but it's generally better to create a new file per style scope.
 *= require_self
 *= require_tree resources/. 

instead of the Rails default of this:

 * This is a manifest file that'll automatically include all the stylesheets available in this directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * the top of the compiled file, but it's generally better to create a new file per style scope.
 *= require_self
 *= require_tree .