Puppies, Flowers, Rainbows and Kittens
Sarcasm and vitriol wrapped in a twee bow.
I had a great time at the BBC Develop conference in London this week. The BBC were gracious hosts, the audience had some good (and not too easy questions) and the program had some really good talks; so I learned quite a bit and met some excellent folks. Special thanks to Tanya Rai, Colin Savage, and Simon Stevenson at the BBC for inviting me and putting on a great day.
You get the main points from the slides. I’ve been getting ever-more-minimal in presentation decks, though. At some point, I will elaborate on these with a blog post or recording of this deck.
I’m don’t spend much time on Quora, but I was reading a different thread and I came across the question: What Makes a Software Engineer Good? Now anyone who has worked with me can tell you that I am pretty opinionated about this subject. So since there wasn’t already someone saying what I would have, I decided to post an answer. Here is that answer:
I’ve interviewed literally hundreds of software engineers over the last couple decades for my teams at Microsoft, Adobe, Spotify and other places.
Over the years, I’ve honed in on a few things that I consider vital for anyone joining my organization. These are the kinds of things that I value as a hiring manager, of course. Others will have their own critical criteria.
These are in a rough priority order.
1) Pragmatism
I don’t bother with tricky or difficult programming questions designed to test a corner of your knowledge or some trivia. Instead I ask a dead simple question. Something anyone could do. Then I complicate it. And complicate it again. And again. I look for the point where you can no longer adapt your very first answer. What I want to know is that you are willing to throw away your first answer when it no longer makes sense. You’d be amazed how many engineers will hack on something that will never work when they could throw it away and do something much simpler in a quarter of the time.2) Interest
Do you actually like writing code every day? Do you read programming blogs for fun? Do you work on your own coding projects outside of work? If this is going to be your job, I want someone who is overjoyed that they get paid to write software. Not someone who’d rather be doing something else.3) Attitude / humility
I’ve worked with brilliant people who are jerks. For every inch they moved the product forward with their innovation or genius, they moved the project back two inches by being impossible to work with. I want someone who is there to make the team better, not someone who feels like everyone just “needs to do as they are told.”4) Intelligence
Yeah, you do need to be smart. Writing software is part art and requires creativity, but it is also a lot about problem solving and just sheer brainpower to figure out why this thing is crashing, but only on Tuesday when the moon is full.5) Programming languages / domain experience
I have worked professionally with a dozen or more programming languages. Some I don’t even remember anymore. While I have a lot of depth in some of them through years of experience, I have been able to learn others as I need to in order to suit the project. I would prefer to see someone with some proficiency in more than one language because that shows some breadth and a willingness to learn, but as long as you can code and are smart (see #4) you can probably pick up whatever language we are working in reasonably fast. I hire for the long term, we can take a bit longer to get you up to speed if you’re a good fit. Similarly with domain experience. If you have an aptitude, we can teach you.I do have a couple caveats to #5 though:
If I’m hiring for a senior position that requires domain knowledge, yeah, that is in the job requirements, so you need to bring that. You would still need to handle 1-4 though.On languages, there is a major caveat. If we’re doing C++ or C, you’ll need to have some experience there. If you’ve only ever worked with high-level, garbage-collected languages, it will simply take too long to really bring you up to speed. I’ve tried this too many times in the past and have realized that it usually isn’t worth the effort.
This looks like a great resource for folks who want to test their web content in a more formal way.
Since getting to Spotify, I’ve been thinking a lot about what makes a good engineering culture and the best way to create, nurture and protect it. There is no simple formula, but I’m starting to understand better the things that have worked well in both the small startup teams I worked in as well as the big corporate ones. I’ve got two talks coming up where I’ll outline some of these thoughts. I hope that it will be insightful or inspiring to others. At least there will be some amusing anecdotes 🙂
I’ll be doing a short talk on Thursday next week at Valtech Days in Stockholm. My talk is specifically on doing real work using Lean and Agile techniques, based on my experiences building products at Microsoft, Adobe and Spotify. The line-up looks really great. It will be an excellent event.
On November 12th, I’ll be keynoting the BBC Develop 2013 conference in London. This will be a much longer talk where I go into the Spotify model of Lean and Agile development, and how it has grown a strong engineering culture. This event looks really awesome. It should be a really informative day. I’m really looking forward to it.
I’m not sure if either of these will be recorded, but I plan to continue talking about this as I keep working on these issues at Spotify. So if the subject is interesting to you, but you can’t make it, stay tuned.
I got a message that my developer subscription for Windows Phone App Store was about to auto-renew. Well, I had created the subscription on a whim (when it was $8 during last years’ Windows Phone 8 promotion), but I hadn’t ever done anything with it. So, I decided to cancel. Thanks to MS for reminding me.
I go to log in to account. I see the subscription like, I click it.
I see my subscription and it’s renewal date.
I click the link to Manage My Subscription.
What the hell? No option to cancel? Ok, I click on the “How can I cancel or renew my service?” link, and I get:
Are you serious? This is really lame.
I click the drop-down and these are my options:
Well, that doesn’t seem right. However, there is a Windows Phone choice… I click the Windows Phone option, and I get:
Which is end user support and is completely not what I need. After finding a link for Developer Support and going to their forums, I immediately find someone else who asked the same question. The answer? File a support ticket. Really. A support ticket. To cancel my subscription? That is beyond lame. That is a roach motel kind of tactic used by shady startups trying to lock in subscriptions, not by one of the most profitable companies in existence. Repulsed, I decide instead to just remove my credit card from my account. They can’t auto-renew if they don’t have my card, right? Wrong.
That is right. Microsoft won’t let me remove the credit card from my account because it is tied to the subscription that I don’t want to auto-renew. Instead it tries to force me to give it another payment option:
This is insane! I’m sure that from the perspective of the PMs and the Developers on the project, this may have made some sense. There might have even been big debates about it. In the end though, someone made the decision that they would force you to go to Technical Support to cancel your subscription. I doubt that they specifically made it difficult to actually go to Technical Support on purpose. I trust by the axiom “Never attribute to malice that which is adequately explained by stupidity.” I’d like to think that the fact that the link to Technical Support effectively sends you to the wrong place and the fact that Microsoft will not allow you to have no payment method on file if you have an active, renewing subscription as two independent, bad, decisions. If you combine those bad decisions with the deliberately EVIL (yes, I went there) decision to force you to go to technical support in order to cancel your subscription, you get a colossal FU to a developer who might otherwise return at a later date. I’ve heard on the internet that other subscriptions are even harder to unsub:
@KevinGoldsmith they try that same crap with Xbox Live, except you have to call into a support center and wait on hold for really long times
— Josh Dura (@joshdura) October 6, 2013
This should be a lesson to anyone building services, especially subscription services. Don’t be stupid and don’t be evil. Make it as easy to get out of your service as you do to get into your service. Make it trivial to export your data. Make it easy to cancel your subscription. Otherwise, you turn folks who may have been indifferent into folks who actively dislike you (what will that do to your Net Promoter Score?) You turn customers who might have otherwise returned at a later date into people who actively tell (or blog!) to their friends to avoid you.
The exit funnel should be nearly as critical as the entrance one. Also, you should actually test that workflow. Again, I’m going to give the benefit of the doubt to Microsoft here. Maybe they didn’t really try to test this workflow like a “normal” person, but given the number of people that work in this area, that really isn’t an excuse.
For those that came across this post by Googling (or Binging) a solution to the un-subbing problem, here is a link to the actual developer support forms so that you can unsub yourself: https://getsupport.microsoft.com/default.aspx?supporttopic_L1=32136142&locale=EN-US&supportregion=EN-US&ccfcode=US&mkt=EN-US&pesid=14879&oaspworkflow=start_1.0.0.0&tenant=store&ccsid=635166677403542430
[Update March 3rd, 2014]
I finally was forced to upgrade for work reasons to 11.1.4. I found a suggestion on the Apple forum and decided to try that.
These were my steps:
So far, this has worked ok (for about 4 weeks for me). I periodically do a check of my library to make sure that no files have been lost and it looks ok for now. I have seen posts on the Apple forum that points to people still having podcasts deleted days after upgrading, so I’m going to continue to check ofter.
I will likely do a similar process every time I update iTunes from now on. I will probably also avoid updating any version as long as I can. Unfortunately, I’ve lost all trust in that application that I have been dependent on for years.
I also want to mention that a friend with contacts on the iTunes team actually forwarded a link to this post and the forum thread as well to some folks in the team. The response (not official, just person-to-person, second hand) was that this wasn’t an issue they thought was affecting many users and therefore it wasn’t a major priority for the team. That may be true (as an engineering leader, I’ve made that decision myself a few times), but as a user it is creating massive problems for, it is of little comfort. This issue may have been fixed by the team anyway, possibly, but the recent comment from Ed, seems to point otherwise.
[Update October 5th – There is a new version of iTunes, 11.1.1, in the release notes it claims that it fixed an issue with deleted podcasts. I installed it. It ran fine for a while (it didn’t fix the podcasts it broke, but it didn’t screw any more up), and then it hung, spinning beach ball. I had to Force Quit it after a few minutes. When I relaunched, it had COMPLETELY REMOVED MOST OF MY PODCAST SUBSCRIPTIONS AND UNSUBSCRIBED ME FROM THE ONES THAT WERE LEFT. Luckily, I had backed up before this happened and I was able to copy over my iTunes folder and relaunch which restored all my podcast subscriptions, until it beach-balled again AND REMOVED THEM AGAIN (I didn’t force quit this time). I then checked my file folders and of course it DELETED MY FILES WITHOUT WARNING, AGAIN!!! DO NOT UPGRADE TO ITUNES 11.1 IF YOU SUBSCRIBE TO PODCASTS! At this point, I once again have to completely reconstruct my podcast library due to poor Apple engineering.]
[Update September 23rd – The Situation is even worse than I thought. iTunes 11.1 is basically useless for podcasts now, see below]
I have been using iTunes since version 1 or 2. I’m not sure. A very long time (nearly a decade). When they added podcast support, I switched from the podcatcher I was using to iTunes and have been using it ever since to sync my podcasts.
While I don’t save every episode from every podcast I have ever had, I do save some of them, which means I have literally years of archived podcasts. Or rather, I should say that I HAD years of archived podcasts. When I upgraded to iTunes 11.1, what I didn’t notice was that Apple somehow unsubscribed me to some of my podcasts or it got confused as to my subscription state. Interestingly, it was the ones that I actually tend to listen to pretty regularly. When it did this, IT SILENTLY DELETEDÂ big chunks of the episodes that had been downloaded from those casts.
This is a data-loss bug, the absolutely worst kind of bug imaginable. A stop-ship bug, a never-release-until-fixed issue. Unfortunately Apple did release it. I didn’t notice that this had happened, but at some point, I got a warning about how I was running out of space on my system drive, so I emptied the trash. I noticed that it seemed like I had a lot more files than I expected, but I didn’t think that much about it (I generally leave files in the trash until I need space). A day or so later, I noticed that iTunes didn’t think I was subscribed to a bunch of my podcasts, and that those podcasts were now missing dozens of archived episodes.
So now I will spend the next several days restoring from my on-line and off-site backups and slowly reconstructing my podcast library. Unfortunately, I now also need to worry about what other files may have been quietly cleaned up by iTunes: music, ebooks, movies? If there are more, I may never notice.
In the end, it means that a piece of software that I have used daily and depended on for years and years can no longer be trusted. The effect of this loss of trust cannot be understated. It would be the first step to me looking for another solution; one that wouldn’t have me locked into Apple’s platform. This is why this kind of bug is so amazingly critical to catch and why missing it is not a small issue, but a catastrophic one for an ISV or IHV.
If you are a long-time user of iTunes, beware 11.1, and everyone should have MULTIPLE backups of their files, for just this kind of event. I’m very glad that I have a complete backup of all my files on a hard drive that I can use to restore and an on-line additional backup in case that drive is busted.
[Update September 23rd]
After several hours of re-downloading episodes and restoring from backups, I relaunched iTunes only to find that it had deleted those episodes AGAIN. This means that this wasn’t an issue with upgrading the database, but rather a much more serious issue. This is beyond a critical issue for people who have large libraries of podcasts in iTunes. It seems that it doesn’t affect other parts of the library, but I’m not sure I can trust that for sure. This is a major issue since I have several iDevices and switching to another application is basically out of the question for the moment. I now have to work around this bug and hope that Apple will eventually fix it while being wary of the app deleting files every time it is launched. As a user, this sucks.
Here is the Apple Support forum thread:
https://discussions.apple.com/thread/5322917?start=0&tstart=0
The release of the first Intonarumori album in a few years gave me a good excuse to redo the website and bring it into the modern internet age.
The release of the first Intonarumori album in a few years gave me a good excuse to redo the website and bring it into the modern internet age.
The old site (still available here) had served me well and the design mostly was still working, but since the updates had been infrequent and minor, it seemed like a big redesign would also be a good way to signal that the site (and band) had not been abandoned, just quiet for a while.
The old site:
The old site was also using a lot of stale HTML tricks (yes tables for layout!). I did do some prototypical responsive design though (resize the window on the old site and watch how the title area resizes smoothly). The site itself also was really bad on mobile devices, and even was using a lot of (horrors!) Flash for audio playback. It had been in place for eight years though, replacing the second design which was from the mid-to-late 90s.
I also thought that the information design was pretty lacking, superfluous information and overly complicated navigation for a musical artist site, ie: way too many pages.
I decided that I was going to try and do it right this time. CSS-based, responsive design, a reasonable layout, retina and mobile ready. I also wanted to follow a true process where I would spend some time sketching and wire-framing before I started in.
I didn’t want to go overly fancy though with unnecessary javascript or dynamic pages, since the site itself should not change too significantly once it is deployed (the last one was in place for eight years).
I spent a bunch of time sketching ideas for layouts and looking at other artist sites to get a better feel for what others had done. Musicians sites are fairly staid I found. Usually relatively minor affairs with a small number of pages and mostly links out to other sites with the content. I didn’t want to make Intonarumori.com into a big destination site, but I wanted to make sure that it had enough information for a curious visitor to get a feeling for the project and it’s output.
Once I had a rough idea of what I wanted to do, I got into coding the first page. I started in with Dreamweaver CS6. I have been using Dreamweaver since it was a Macromedia product, almost since it was released. My earlier sites had been done completely in notepad and e-macs, but I loved being able to do WYSIWYG HTML and having a built-in FTP server. Dreamweaver also has really good CSS. I had been finding its’ limitations though on some projects over the last few years. Especially on sites like kevingoldsmith.com and parts of unitcircle.com where I was mixing PHP elements in. Dreamweaver started to be more of a hinderance than a help there.
I decided that I didn’t want to use Dreamweaver’s built-in support for responsive design. Not that it wouldn’t have made things much easier, but I wanted to really understand how to do it right myself before I started using tools. Also, I had just had to rip out a lot of old Dreamweaver template crap from one of my old sites and I didn’t want to get stuck into anything Dreamweaver-specific.
I did want to use JQuery, so I could learn it better. So, I did use that and I also spent some time looking at different responsive design libraries. They were all a lot more than I needed, so I decided to do stuff myself. Again, a goal was to really wanted to understand responsive design better.
As I got into using more Javascript for messing around with the DOM, Dreamweaver immediately became useless for viewing the content. The split view, which I had really loved, was basically worthless. Dreamweaver became a pretty-good text editor with pretty-bad FTP support added in. (aside: the FTP support in Dreamweaver seems to have been stuck in maintenance mode for the last several releases, which would have been fine if it actually worked well, but it never has). I found myself editing code in dreamweaver and then having to FTP it to my server to test. Dreamweaver used to let you preview in a browser locally, but either that got removed or just moved to where I couldn’t find it. This process became unworkable to me. I decided that it was time to move on to a different process.
I have been using TextWrangler for a bunch of different code editing projects, so I decided to try it out for this. I came up with a new process where I edited the code in TextWrangler, previewed by reloading the page in Chrome, and then pushed it to the server to check on other devices by using SFTP in a terminal window. While this might have seemed like taking a big step backwards, it actually worked ok. At least as well as Dreamweaver, if not a bit better. The lack of code completion was starting to bug me though, and having to type FTP commands constantly was also getting annoying. So, I decided to look into better tools now that I knew I had to drop Dreamweaver.
My first change was buying a copy of Transmit 4. I have to say that I love this app! Being able to mount the webserver as a virtual drive and edit the files directly was awesome as I was messing with the media queries in the CSS and modifying the layout for mobile. It was also amazingly faster and more reliable than Dreamweaver or shell FTP.
I wanted a better editor though and I asked on Twitter to check with the zeitgeist. Of course my pals at Adobe put in plugs for Brackets:
@KevinGoldsmith how are you not using @edge_code or @brackets?! It sounds like exactly what you need.
— Ryan Stewart (@ryanstewart) September 2, 2013
I had known some of the Brackets guys and I liked that Adobe was doing this kind of open source project, so I grabbed a build. For an early build of a code editor, I thought that it was pretty good, but I found some of its quirks a bit frustrating. I was doing a lot of refactoring of layout code at this point and I was finding myself fighting the tool a lot. It was better than Text Wrangler and Dreamweaver, but it wasn’t really working for me. I decided that I need to keep looking. I did like the live update in the browser feature though, that is pretty cool.
Of course I was well aware of Sublime text, but I had never actually tried it. The videos on its site scared me a bit. It seemed way overly complicated for my needs, and the idea of having to use code and to hand-edit preferences files to use a text editor were not really appealing. I might as well have dug up my old .emacs files and started there again. I decided to give it a shot though given multiple recommendations from folks I trust.
@KevinGoldsmith Try Sublime Text and some packages from https://t.co/wAlh9VWN8t. Or try http://t.co/yzPIwg6QsP, bit early thing from Adobe.
— Mattias P Johansson (@mpjme) September 3, 2013
While Sublime isn’t perfect, it is definitely the best one I’ve tried yet and seems to work. I’m using Sublime 2 now, but will probably check out Sublime 3 soon.
I also realized that rather than use my devices all the time to check out how the site worked on mobile I realized I could just use the iOS Simulator that comes with X-Code. That was a massive improvement to my workflow as well.
So new workflow is:
I didn’t mention GIT before, but I’ve been using it on all my sites for a while now. Especially the WordPress ones. In addition to being able to roll-back a site and try out some stuff worry-free, it is also great hacker repair. If any of my sites diverges from the local HEAD then I can figure out what files have been messed with. I haven’t used this to actually use remote repositories as ways to update a site, but I may eventually.
With my workflow in place and a few pages done, I pretty much had the process of building responsively going pretty well.
At first, I was trying to make the site smoothly re-lay itself out for different sizes dynamically. This was way too much work for too little gain as HTML does a pretty good job of that on desktop and it isn’t an issue on mobile. So, after wasting some time on that I switched to doing more with CSS Media Queries. This was fine, but I got way too narrowly-targeted there which meant a lot of work targeting different mobile platforms. Eventually, I switched to having a few basic layout for different widths, roughly one for phones and one for tablets and then one extra one for phones in landscape mode. This worked well on the devices I have, and it kept the effort to be reasonable, but I still need to test on friends devices to make sure.
Now the new site was pretty much done:
There are still some things I’m going to tweak and probably a few issues here and there, but overall I’m happy with it as a new starting point.
There were a couple other resources that I used that I want to give a shout out to. One was the icon set I got from G. Pritiranjan Das. For the photo page, I used the Camera Slideshow JQuery plugin. I also used Matt Kersley’s Responsive Design Testing tool and found it useful.
I thought of this as I was writing the previous post, but decided that it was important enough that it deserved it’s own discussion.
Another benefit of physical agile boards is that, by their nature, they tend to limit the scope of your planning. To some, this may sound like a bad thing. It is actually one of the most difficult disciplines to maintain in agile development.
One of the things that distinguishes agile development from older development models is that Agile keeps the time horizons close. This is beneficial because the nature of software and systems development is ever changing, and long-term plans are almost always upset by the realities of the industry and of development itself.
Even strong agile teams see opportunities and features that don’t make sense right now, but they know they will want “someday,” The tempting thing in Scrum is to add these into the backlog, so that they aren’t forgotten. In Kanban, they may go into the “not started” column or some other “feature stash” (The Product Owner and I had a secret Trello board called this when I worked on Revel at Adobe). These far-off stories and epics become their own drag on the agile process, slowing down backlog grooming and sprint planning as the backlog becomes less and less manageable and stories get re-added because no one can find anything.
A physical board actually makes it physically difficult to do this kind of faux-waterfall long-term planning. There just isn’t anywhere to put the post-its/cards! The Product Owner may still have their personal feature stash somewhere, but it won’t become a drag on the whole team.
Similarly, the lack of physical space makes it difficult to over-plan the stories that are in front of the team too. When I was doing Scrum as front-line engineering manager, I found it difficult to figure out how many stories we should break down for a sprint in order to not run short. The tendency was always to task out a lot more stories than we needed, just-in-case. The virtual board makes it easy to plan as many stories as you want. In practice, stories have dependencies on each other and if you over-plan, you tend to just write incorrect tasks.
A physical board encourages you to plan just as much as you need, and not much more.
After years of exclusively using virtual Scrum and Kanban boards, I am using physical boards again. In the process of adapting, I’m rediscovering many great things about using a physical board. One benefit of a physical board that I didn’t expect is that your stories and tasks tend to be less formal.
Last week there were two stories on two different team’s boards that made me laugh. One was:
The other (which I didn’t get a picture of) was “do the thing with the thing“.
A good agile coach would point out that both of these were under-specified and poorly written. A better agile coach would point out that as long as the whole team understood what they meant and there was an agreed-upon definition of done, then the wording doesn’t really matter that much and it is fine for the squad to have an occasional story like that.
Neither of these would have ever appeared on a virtual board. By being on the computer/net, the virtual board has two features that the physical board does not.
One is longevity. “Do the thing with the thing” is fine if it is a story under discussion every morning at standup, and tossed in the trash when it is done. “Do the thing with the thing” would be a cryptic mind-f*ck a few years or even weeks later if someone was reviewing old stories.
Now this longevity element is something that I used to like with the virtual boards, having the history and being able to see how things developed and where they came from. In reality, you don’t really ever have time for that and instead it becomes another digital barnacle that isn’t really that useful.
Another property of a digital board is transparency. Theoretically, anyone in the company can see it. This again, is both a positive and a negative thing.
Having a board that anyone can see means that what your team is doing, will do and have done is available to anyone. Status reports are (theoretically) not necessary. If anyone asks what you’re working on, you can tell him or her to go look at Trello/Pivotal/Jira/etc and bug you if they have any questions.
With a physical board though, they need to come to the team and look at the wall. This means that any misunderstandings can be cleared immediately, and communication is actually improved by, you know, people speaking to each other.
When you are creating stories, tasks and notes on a virtual board, you are writing for an indeterminate audience. You are writing for yourself and your co-workers, but you never know who else will be reading it. If something you write has to make sense to anyone, ever, you will be a lot more guarded in what you say. You will be wary of not only how the story is perceived, but also, how you as the author are perceived. It is the difference between the conversation you have with a coworker over a beer and the item that you post to a blog or twitter.
That consciousness of the potential audience takes all the spontaneity and fun out. The formality makes stand-ups and planning take longer as well.
If you work on a co-located team and are using a virtual board for your agile practice, try going old-school for a while. I’m betting that your stand-ups and planning will go a bit smoother if you know that the stories and tasks that you write are for your team’s eyes-only.
Whatever you do, don’t forget to do the thing with the thing, and while you are at it, unf*ck everything.
