Leading Softly

I'm coming back to blogging after a few years buried under project work, and I want to explore some lessons learned as a technology leader managing a department growing rapidly and going through significant changes. My department builds educational software products and has grown from a couple employees and a dozen consultants to over 70 employees and 100 contractors/consultants over 3 years.

The saying goes, "What got you here, won't get you there". This is especially true for leaders in technical fields like software engineering. It means you probably have the hard skills (coding, automation, design, coordination, etc.) and logical problem solving that helped you be successful as an individual contributor. Now you are in leadership and probably finding those skills are not helping you solve the same problems. Here are a few lessons I learned last week of the softer skilled sort.

1) Unmet expectations are the root cause of upset people
If you are dealing with friction with someone at work (or helping 2 people in your team deal with their friction) then your best option is to look for the unmet expectation. Maybe they expected to be treated with more respect, or that you would be on time for the meeting, or that something would be done more quickly. Try to determine what the unmet expectation was and help address it and you will remove the source of the problem. This alone won't solve everything but it will help resolve the issue.

2) If you impact someone else, then at least inform them, and ideally engage them
This is easiest to think about using some examples. Are you waiting on something from another person in order to get your job done and it is late but you haven't heard anything? Do you depend on a process controlled by someone else to get your job done? Have you been pulled into a meeting beyond your control without knowing why? Do you get assigned to projects without having a say? All of these are examples of being impacted by the decisions of someone else. This is pretty common and probably pretty annoying for you (or whomever is on the receiving end). If you are the one causing the impact to someone else, try to always keep them informed. If there is flexibility, then engage them in the decision making about it (even if you only ask for their feedback). You would want this if you were in their place so treat others like you want to be treated.

3) Good communication is the key to everything
I've come to realize that most relationship and work challenges are caused by poor communication. Did servers go down during a recent release because the database configuration was mismatched between prod and dev? Bad communication. Did a recent feature get built differently than customers wanted? Bad communication. Are users angry because a bug was released that the testers knew about? Bad communication. Was someone surprised by bad news that they should have been aware of? I think you get it... The simplest step to improving communication is to simply take the extra time to do it. It's not a magic bullet, but most poor communication happens because we didn't bother taking the extra time to communicate for understanding. Try asking people to echo things back when you talk to them this week and do them the favor of doing the same. You won't regret spending some extra time on communication but you will regret not doing it when things go wrong.

Also find this on Medium and LinkedIn

My first week with Groovy and Grails

I spent time over the last week learning about Groovy (a dynamic language for the JVM) and Grails (a code by convention web application framework built on Groovy) so I thought I would write up my impressions and some of the fun things I learned.
So you have a sense of where I am coming from, I am a long time Web applications and Java/PHP/Javascript/Perl developer. I am somewhat newer to Python and Ruby but I prefer Python. I am a REST and Open Source advocate when I am in the right mood.

If you are totally unfamiliar with Groovy then I recommend you take a look at this post as it lays out the reasons why you might want to learn more about it:
http://codetojoy.blogspot.com/2009/06/case-for-groovy.html

If you know you are going to be writing web-apps then just skip Groovy and go straight for Grails. If you are looking to do some JSR-223 (Java Scripting) stuff (with Groovy) then Groovy is the place to focus on. Either way, you will need to get familiar with the basics of Groovy so look at these:
http://groovy.codehaus.org/Quick+Start
http://groovy.codehaus.org/Collections
Feel free to checkout some sample Groovy scripts I made which illustrate many of the key concepts.

The Getting Started Guide for Groovy is huge and not really a very good place to try to get started unfortunately. That said, the Beginners Tutorial is pretty good, especially the section on closures.

If you want to get going with Grails then it is a little bit easier since it mostly builds on Groovy. Grails borrows heavily from Ruby on Rails so if you are familiar with it then things will come to you quickly. This is the best place to start (not surprisingly):
http://www.grails.org/Quick+Start
I really liked the screencasts (which are oddly located here also). They provided a nice introduction to Grails without much effort. When you are ready for a little more the tutorials are a good next step.

Things I learned in no particular order:

• Maven and Grails do not get along - There is some really weak maven integration available but it does not work very well. The structure of grails (e.g. src/groovy) does not match the maven standard structure (e.g. src/main/groovy). Mostly maven just allows you to run the grails build commands which is easier to do with grails itself. I struggled with this for awhile before just giving up on using maven. The Grails team recommends using Ivy if you want to add dependency management (or Grails plugins which are preferred if they are available).
  The grails and groovy artifacts are available in maven repositories which is nice.
  
• Grails and Eclipse don't easily integrate - The Groovy plugin is pretty good (not great) but the build integration is pretty poor and requires you to jump through hoops. It seems like the integration with IDEA is a lot better and recommended by the Grails team.
• Groovy supports closures - The closure support in groovy is great and very easy to use. I found myself writing closures like crazy (even more than in Javascript) and it made the code very clean.
  NOTE: I ran across one weird bug where passing in a String[] to a closure causes it to be misinterpreted as a collection of separate arguments for each array entry. There are hacks to get around this but be aware that it may bite you.
• Grails has a great plugin system - Grails has a pretty powerful plugin system which allows easy extension of a grails app. The plugins seems to be very easy to install and fairly easy to write. There is a complete guide if you are interested in developing your own plugins.
  
• Grails app creation puts in too much stuff - The structure generated by grails create-app has a lot of stuff in it which you will probably want to cleanup (like the hibernate plugin by default for example). There is no uninstall for plugins so just remove the dir of the plugin to get rid of it. Be careful to not leave in a lot of things you are not going to use and clean out the sample stuff under web-app as well.
  
• Grails convention is not very flexible - Grails prides itself on "code by convention" and "convention over configuration" and it does a good job of establishing a lot of conventions. It takes a little while to get used to them but if you follow them then things are pretty easy. Unfortunately, this implies that it is possible to override the convention using configuration if needed and in many cases it is not. I have been bitten a few times already when I tried to do things that are not "on the rail".
  
• Grails uses prototype.js by default - The built in javascript engine in Grails is the portal/multi-framework unfriendly prototype.js. I can't use it so I am playing around with using jQuery instead (so far this is proving to be manageable). There is a jQuery plugin which helps make this easier.
  

I am still getitng used to things but I am not sure what Groovy/Grails gains me over using Jython/. It seems like Jython does everything Groovy does plus it has the massive Python community for support.
As far as scripting languages go I think I prefer PHP, Javascript, Python, and Perl (in that order) over Groovy but this may just due to a lack of familiarity on my part.