Useless Hackathons

I participated in a few coding competitions in high school, where we got together for a day with a team and tried to build software to solve a problem. They were challenging and exciting, but exhausting. Not something I’d want to do often.

A number of corporations have tried something similar with internal hackathons as a way to find internal innovation and inspire employees. Getting a day, or a few days, to build some software that might change an organization can be exciting, but the events are not without some drawbacks.

I’ve liked the idea of us doing this at Redgate, with our Down Tools Week, but the CIO of TD Ameritrade finds hackathons useless. The reasons he gives makes sense, and they are problems I’ve seen in various organizations when employees want to build something new, without necessarily understanding the problem or having the resources to complete their work. I mostly agree that unbounded hackathons are problematic, and having some evaluation of ideas is important.

It’s hard to be innovative constantly in an organization when you have pressures and deadlines to complete work. At the same time, it can be easy for an entire development department to stagnate because writing software to close out tickets someone else has submitted. That’s boring, uninteresting work in many cases, and it can reduce incentives to build great software. The ideas in the TD Ameritrade piece are good, allowing a team to be sure developers aren’t solving a problem that’s been evaluated, or choosing a solution that is impractical. I like the idea of funding ideas and increasing that over time if ideas show potential.

Ultimately there are often lots of ideas on how to solve a problem with software, but we rarely work in a vacuum. Our solutions have to fit within an existing structure and have a ROI that makes sense to the organization. Whether we sell software or support some other business, we are trying to achieve those goals, not just solve the problem in the most satisfying manner. Too often I think software developers sometimes forget there are goals other than just producing code that completes a task. Usually those goals are furthering the organization in some way beyond the software.

Steve Jones

Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

Posted in Editorial | Tagged | Comments Off on Useless Hackathons

Daily Coping 14 Jun 2021

I started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag. 

Today’s tip is to eat good food that makes you happy.

Diet is important, and what makes you happy isn’t always what’s good for your body. Certainly moderation matters, but I’m also not someone that wants to deny myself food constantly and miss out on life.

For me, pizza is one of those things that I really enjoy. I don’t get it often, or make it, but I did the other day. After a good workout, I swung by a local place for a couple slices to unwind and enjoy a little life.

Posted in Blog | Tagged , , | Comments Off on Daily Coping 14 Jun 2021

Beer Mode

David Perell has an essay on the different ways that creative people work. He calls these “beer mode” and “coffee mode”. When you are in coffee mode, you are getting things done. You have a list, and you work towards accomplishing the items on your list. Lots of us spend time in this mode every day, and often our bosses expect us to spend more of the time here. This has also been described as “closed” mode.

Beer mode is different. This is an open mode, where we are not focused on solving an idea, but rather playing with something. We are thinking widely, investigating, and not necessarily planning on getting something concrete completed.

For much of my career, I was in coffee mode. I think my ability to take a list and get things done contributed to my success in various positions. I could grind through a set of tasks, even repetitive ones, and show my boss what I’d accomplished each day. Going through a list quickly, even if slightly inefficiently, was often rewarded.

These days, I spend more time in beer mode. Not actually drinking beer, but rather experimenting, playing, thinking, and trying to find new insights into the database world, into how customers might re-imagine their use of our products, and how computing and technology can inspire the world. Those are the fun times. I still get a fair amount of coffee mode in editing, scheduling, etc., but I get more playtime than I ever expected in the past.

We need both types of working. Often we do want focus and concentration. This is where we build skills, develop strong habits, and produce something valuable. This is steady growth. However, we also need creative time. This is where we expand our minds, think outside the box, and how we grow in leaps and bounds. At least, we may. We can’t predict when we have a breakthrough or find an “aha” moment, but all of us have them, even when they are not life changing.

Some organizations are better than others at allowing some “beer mode” time at work. If your boss doesn’t think there is a need for unstructured work, maybe send them the essay above and see what they think. There might be all sorts of reasons why this doesn’t make sense every day, or every week, but I do think that having some experimental time is important for anyone doing creative work. This includes the DBAs and sysadmins trying to get your system to run better without a large budget.

Steve Jones

Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

Posted in Editorial | Comments Off on Beer Mode

Using SQL Compare for One Procedure

A customer recently was concerned about the time to run SQL Compare for a large database. They were synching with the command line, but at times they want to just sync up a procedure or two from one database to the other.

I knew this could be done and passed along some ideas, but decided to write a post. This post looks at how to do this.

A CLI Comparison

The SQL Compare command line is pretty easy to use. Lots of switches and options, but the simple thing is point it to a couple instances and databases and get a comparison. Here’s a command line.

sqlcompare /server1:Aristotle\SQL2017 /server2:Aristotle\SQL2017 /database1:compare1 /database2:compare2

And the result. You can see below I have a table and three procedures that are different.

2021-06-09 17_31_32-cmd

If I want to limit what’s compared, I can certainly use a filter, but from the command line, there’s a simple way to see certain objects. There is an INCLUDE switch that I can use to just set a filter here without creating a file.

For example, if I want to just see stored procedures, I can do this:

sqlcompare /server1:Aristotle\SQL2017 /server2:Aristotle\SQL2017 /database1:compare1 /database2:compare2 /Include:storedprocedure:

This gives me just my three stored procedures.

2021-06-09 17_42_14-cmd

Likewise, I can also change this to a table and just get that object.

2021-06-09 17_42_33-cmd

If I want a specific object, I can get that as well. Here I use the include like this:

/Include:storedprocedure:\[GetMyTable\]

Then I get just my one object, with a faster compare. Only this one is checked.

2021-06-09 17_44_12-cmd

Then if I add the Synchonize switch, the changes will get deployed.

I often find that people are looking to deploy quickly just a known object or two for some hotfix or out of band change. Using the command line let’s me pick an object that I know about and build a comparison for just that object.

There are lots of options and ways to use SQL Compare, and I’d urge you to explore a bit as you look to improve your database deployments. If you don’t have it yet, download an eval and give it a try.

Posted in Blog | Tagged , , | 4 Comments