We often mistake the job we see managers doing with the job they are really doing. We’ve all asked, at one time or another, “What does my boss actually do?”. We see them go to countless meetings, ask questions, or send around documents. We then equate those activities with the actual job of being a manager. Until I was promoted into the role of my departing boss, the perception I had of what they did was totally different to what I found myself doing. There was all this unseen work going on behind the scenes that led to the countless meetings, that led to the questions and that led to all the shared documents. On-top of that, the un-seen time and thought that went into ensuring the right questions were being asked and the right documents were being created and shared. This is no different to equating Engineers to writing code. There is so much unseen work involved in writing the right code. It’s knowing what technologies to use, it’s knowing what techniques, data structures and algorithms to use, and it’s knowing how to put it all together into building a functioning product.
All posts filed under “work”
Not so remote
Fostering a team feeling when everyone is remote can be extremely difficult. It’s easy to feel like you are working in a total silo, and can be made worse if everyone is spread across distant timezones. Being able to function as a team is a key component to project success. Feeling isolated and alone when problems come up can make work frustrating and stressful at times. Here are a few ways to try and overcome that:
- Try and arrange core hours where the whole team is available and together on Skype/HipChat/Slack.
- A weekly call with everyone to update on work, issues and client feedback.
- A daily call between project managers and members of the team to chat about current progress and the project as a whole.
- Code sharing sessions. Show code to other members on the team and explain what features are and how you’ve gone about implementing them.
Battling Procrastination
An absolutely brilliant two part series on procrastination. My most hated enemy.
Part 1: Why Procrastinators Procrastinate
Part 2: How to Beat Procrastination
Small teams and interruptions
It’s hard for non-programmers to understand just how bad interruptions are when it comes to being a productive coder. While most jobs suffer from the same problems of “getting back into the flow” after being interrupted, programming is especially difficult as normally programmers are trying to hold a number of structures in their head at any one time so as to solve whatever problem it is that they are working on.
In most small companies, the development team is might only consist of three or four people and in such a small team with a large backlog to deliver, it’s not normally the teams size that is the main factor in being able to deliver large amounts of work, but all the small interruptions that happen during daily business. Asking a developer that is sitting close by about when a feature will be ready or whether something can be fixed/changed is all too tempting and easy to do. Why IM or email when you can just shout across the room. It only takes a few 10-20 second interruptions to change a productive three to fours hours into just maybe one or two.
Once a company grows these sorts of problems can be smoothed out by having someone act as a barrier to the developers, shielding them from minor questions/requests and letting them continue with their work until free to discuss them. Small companies don’t have the luxury of assigning someone that role so need to find other means to minimising that contact. It’s important that someone sets some ground rules. It could be as simple as there is a set period of time every day that programmers should not be disturbed or communication should be limited to IM and email if possible. Just removing the constant stream of “Is X ready yet?”, “Did you get a chance to look at Y?” or “Would it be possible to do Z?” would mean a huge productivity boost for your programmers and overall deliverables for your company.
Stupid and gets stuff done
Getting stuff done isn’t all about writing code or producing. It’s about delivering value and something worthwhile. I could write code all day, but if it’s of no use to anyone, then my code has been for nothing. The famous Patton quote says “A good plan violently executed now is better than a perfect plan executed next week” and I believe something along the same lines holds true for programming: “Good code deployed today, is better than perfect code deployed next week”.
New Office
Out with the old and in with the new.
So you want to be a developer?
I’m so glad that I’m not just getting started as a web developer these days. Facebook is the main example I give to people when talking to about this. It has set the standard for what and how people think a web app should behave. Move forward or backwards through photos and they are dynamically loaded without refreshing the page. Send someone a message and a modal box appears with autocomplete on the textboxes. You can browse the site, chat to friends and do all sorts of stuff without ever having to experience a page refresh. I even remember when they added AJAX to their photo albums. I mentally flipped as it made the site so much more usable. I showed it to someone going “Look! Look! There’s no page refresh.” while they just shrugged and went “I don’t see what you mean.”, D’oh… exactly! The sort of stuff no one even realises is happening. But I’m sure they’ll feel the difference if they use functionality on your site that’s similar to something Facebook does, but which requires a refresh where as Facebook doesn’t. Even I feel the pain of moving forward and backwards through photos on Flickr. After the third or fourth page refresh, I just give up.
When I got started, web stuff was so new and so simple that in hindsight it was amazing what you could get away with. You could just fly by the seat of your pants. I know I did. The first piece of web development I ever did was back in the mid nineties two days before my first interview. I wrote a Java servlet that simply took a single text parameter and queried a MySQL database using JDBC. I showed it at the interview and got a job as a web developer using Perl. I didn’t even know the Perl but still got the job. All I had to do, day-in, day-out was write HTML and scripts that responded to clicked links or submitted forms. Submit, refresh and display the result, job done, I can go home now. Creating a site wasn’t hard, almost anyone could do it and almost everyone was at the time. Life was simple and it was pretty much a level playing field. Now though, it is a totally different ball game. You’ll need good knowledge of at least a couple of languages, HTML, CSS (Yes we need it to work across all the major browsers), SQL, Javascript + a framework like jQuery + how to use AJAX.
There is just so much that you need to know that if you’re not doing this in your spare time, how are you supposed to ever compete with the kids nearly half your age who can already do this stuff with their eyes closed. Even me, who does this stuff every day as a job has to learn more and more if I even want a chance of staying relevant and employable. I love learning, so it doesn’t bother me. Programming still turns me on and it has to if you ever want to make a go of doing this for a living. Sometimes you can be in the fortunate position of working for a company that really loves this stuff, so you can learn and grow, but I suspect the majority of IT related jobs are done in companies where IT is a second thought to their overall business goal. Where managers prefer to say “no” to your ideas rather then say “ZOMG we could totally awesomely AJAX dis bitch up!!!11!”. And the learning doesn’t just stop at work related subjects. There’s a lot to be said about learning new languages and techniques totally unrelated to your work. Not only for the mental stimulus but also how they can teach you to approach a subject in a new way. I admit this is perhaps one area where I don’t spend enough time, but I’m trying. So go forth and learn. Be totally fucking awesome.
From 0 to 100mph
Drivers to your cars
Get a car, fill it with gas, put some sparkly rims on it, dress it up in a body-kit, stick some brand name decals on it and step back. What happens? nothing. Nothing happens without the driver. Nothing happens without someone getting in the drivers seat, turning the key and stepping on the gas. When it comes to performance and chatting about car lap times, a lot of people will say, that the average Joe in the same car won’t even come close to the same lap times as the pros. The same is true of software teams.
Get a project, fill it with time, assign some developers to it, dress it up in a “respected” language, stick some brand name methodologies on it and step back. What happens? A whole world of pain. Pain happens without a driver. Pain happens without someone getting into the drivers seat, making sure the whole team is constantly onboard and steering them forward.
Change follows the leader
Change needs a leader. Someone who can inspire and lead the team out of the darkness and into the light. I suppose what’s really needed is a project Jesus. The one true light and way. Someone who can mentor and guide those less informed on the various subjects, so that they can go forth and do likewise. Someone who can keep an Eagle eye view of the whole project and swoop in when things start to go a bit off course. Someone to be the general go to guy. I don’t mean bug the poor guy every five minutes, but use their knowledge to forward yourself. Read their code, study their tests and bounce ideas off them.
The collective is not enough
For a team to change, it’s not enough for the team to suddenly try and change course. A rudderless team will go nowhere, or funnily enough probably in a circle. While few may be motivated, and some willing, it’s likely that a few will stand their ground. Flipping burgers is a departure from making subs, but it’s all in the game. The evangalists and the nay-sayers each have their demons and each can just as easily de-rail the train to the end goal.
When change comes about, those who championed the ideas or were motivated to put them into action are fuelled and ready to go, but energy quickly runs out when faced with un-answerable questions because of the knowledge hole in the team. “The client wants this task done asap, how does this affect the sprint?”, “I’ve got this class here which calls this class and this other method, how do I unit test it?”, “Who knows how to set-up a CI server?”. The answers to theses questions are readily available on the internet, but a lot of it can be very subjective as well. Everyone has their limit. It’s tempting to by-pass the iteration and just slip the new task in, because it’s hard to tell a client you’re going to bump something from this iteration to meet their request when you’re not used to doing it. It’s tempting to skip testing that method, because it’s hard to refactor the code to make it testable when you’re not used to doing it. It’s too tempting to keep making builds by hand, because it’s too painful to learn how to implement CI when you’re not used to it.
Understanding and team buy-in
For change to be most effective, the whole team must understand why change needs to happen and how all the seemingly independant parts come together to achieve a common goal. If we don’t understand why, then we can never know how. But the why and the how put together does not always lead to the actual practice. For years I knew why TDD was better. I knew that I should be doing it. I knew that I should be writting my tests first, but I still didn’t. I knew how (or at least I thought I did), but I didn’t bother. The most obvious answer as to why I never did it is laziness, but I think the problem runs deeper then that. Yes, laziness is a factor, ignorance is another, but overall I hadn’t bought into the idea of TDD. I had not invested enough time to ever feel the benefits or to convince me that this is what I need to be doing. I had become de-sensitised to the pain of regular coding and debugging. It was only in that ‘a-ha’ moment, where testing and coding seemed to just flow and work, that I bought into it totally. I was convinced and couldn’t imagine ever going back.
People need to believe in the change and rally round it. People need to feel like it’s for their own benefit (which it is!) and not just for the company they work for (which in the end also benefits!). Work done in dis-belief and cynicism is never a job well done. You get out, what you want put in.
Don’t be a DSL (a.k.a When Developers Go Stale)
I’m not talking about being a Domain Specific Language, I’m talking about being a Domain Specific Loser. These are they people who don’t go to the trouble, and it is trouble, of broadening their skills and learning new things. They are the people who don’t care about anything that doesn’t have anything to do with what they are working on.
Hey, I didn’t sign up for this!
Technology is such a fast changing industry, that if you don’t keep up, you’re going to get left behind pretty fucking quickly. I had a load of things listed as points that every developer should be doing and then came across a post by Jay Fields which summed it all up perfectly:
- Have you tried Test Driven Development? Can you name something you liked and something you disliked?
- What language(s) that are gaining popularity, but not yet mainstream, have you written Hello World in?
- Do you read books or blogs looking for new ideas at least (on average) once every two weeks?
- Do you at least attempt to learn a new language every year?
- If you don’t understand a requirement, do you IM, phone, or go talk to the business?
- Have you ever run a code coverage or cyclomatic complexity tool against your codebase?
- and so on…
On average, 50% of the people I’ve worked with cannot answer those questions correctly. If you can’t answer them correctly
- You’re junior and could use a good mentor.
- Or, it’s time to find a new profession.
Developers go stale. It’s just a fact. I was stale and then I discovered Ruby on Rails and I was born again. I don’t mean that to say that Ruby on Rails is the light, but rather that Rails opened my eyes to doing things ‘better’. It got me excited about technology and programming again. It got me constantly thinking “How can I improve?”. And since then it’s been a long steady stream of new ideas, new techniques and new tools. Groovy, Grails, Git, Proper CSS, TDD, Agile, Scrum and of course OSX, etc. I am spending increasing amounts of time buried in blogs or books. Clean Code was a complete eye opener and my current read, Refactoring to Patterns, has me feeling like I am attaining programming Zen.
I think a lot of developers kid themselves into thinking they are developers. Even after working as one for nearly ten years I still feel like I’m a scraping off the bottom of a very deep barrel. Being a shit programmer is easy, anyone can cut and paste some code together, but where is that going to get you? When you hit 30+ are you really going to have the skills necessary to start jumping into to the £50k+, £75k+, £100k+ salary bracket? No, you’re not. Sorry. At that point, we’re playing for high stakes, and they don’t hand those jobs out to just anyone. If you’re a developer and reading this post, take a look at those Jay Fields’ questions again and be honest with yourself. If you can’t answer them correctly, you should seriously take a long hard think about what you’re doing with your career. You should be doing something you care enough about, that you want to be as good as, if not better than, the people at the top of the game.
Being shit is easy, being good is hard. We live in a world where no one wants to do anything for themselves, but that’s not how the world works. So do the right thing. Step outside the comfort of your regular language, read some books, read some blogs, try some new techniques. That’s all you need to do. Don’t allow yourself to become stale by working within the confines of your 9-5 job, its codebase and the developers around you. You need to step out of that mentally to really see what’s going on in the world of technology. I’ve probably learnt more from developers I’ve never met, then those that I’ve sat next to for years! If I hadn’t stepped out of such a silo, I’d still be developing applications in Struts, forever re-compiling and restarting the server, wishing there was an easier way. Now that I’m using Grails, I don’t know how I ever got by before. And with all the lessons and techniques I’ve learnt over the past six months, going back to those old Java/Struts applications is a joy, as it’s a chance to flex my muscles and do some fun refactoring and sprinkle some syntactic sugar around (Nothing is more satisfying then sweetening some smelly code).
It’s hard for some people to swallow. Being a developer today is not what being a developer was 5 or 10 years ago. A lot of people don’t want to adapt, and that’s fair enough, but that’s how species become extinct. They don’t adapt. Being a developer today is about so much more then just developing code. It’s about delivering solutions. From soup to fucking nuts. We should be able to interact with customers, spec out pieces of work and participate in groups to ultimately deliver on a customers’ need. It’s a bitter pill to take but that’s what the job is. It’s a far cry from what it was before, where writing software was like a holy quest, and the crusaders could never be questioned for fear of ever increasing budget and timing overruns. These days there are companies delivering software of such high quality and at such a high pace that customers become understandably agitated when their developers fail to do the same. There used to be a time where you could deliver a piece of shit and get away with it because people still didn’t really understand the web and what it was capable of. But you’re damned these days as clients want the same small features that make sites like Facebook, Gmail or Yahoo a pleasure to use. “What do you mean you can’t do it? XXX does! How hard can it be?”. Ouch I hope you’re up-to-date on your skills when that question comes around.
Investing in Your Own IT – The Ultimate No Brainer Pt. 2
This is a follow up to my previous post about investing in your own IT. The more I think about the more I keep coming back to the thought that it’s not about investing in IT, it’s really about investing in your people. After all, without your people you’re nothing. Yes, without your people you are nothing. Zilch, nada, zero, nil, null.
You’re not spending money on new computers so that tasks are done faster or made easy to achieve. To claim that is to say that the key to success lies within the tools. It doesn’t. It lies within the people. “Well”, you may say, “then it doesn’t matter what equipment I give them then!”, and with that you would join the many number of managers I’ve heard say the exact same thing and who I believe had no a clue as to what their people actually did. Good tools do not create good developers, but bad tools do create bad ones. And I don’t mean bad in the sense that all of a sudden they start writing bad code, but that they become de-motivated, uncaring and uninterested in their work, to the point where it has a significant impact on their deliverables.
Now you could say that a developer worth a dime will rise above and make best with what they’ve got, but we’re a proud bunch of people and of course want nothing more than to do good. But if you begin to even start to feel like you’re being set-up to fail or that you are not important, then it’s lights out and that is going to have a major impact on your motivation and which will affect anything that you are supposed to deliver. A motivated developer will always create something faster, better and stronger then one that isn’t. A motivated developer is a productive developer.
“Hey, I’m paying these monkeys! So they can just lump it or get the hell out.”
Well at least you are brave enough to admit that you’re paying people to put up with your shit. But why? Why be shit? Isn’t there some part of you, deep down, that just wants to blow the fuck off the roof and do extraordinary things? It all comes down to self-development, whether that be the self as an individual or the self as an entity, like a company. I touched very briefly on the subject in my post about typing, the short of it being, if you have the opportunity to improve, why would you not do it? There are, of course, reasons not to. Perhaps it’s fear. There is the fear that if you make the effort to try, that you will fail and others will laugh at you, or there is the fear that the actual process of trying to improve will only expose your flaws, and no one one wants to be exposed as being a complete moron (You know who you are). Perhaps it’s monetary. To get better, you may need to buy new equipment, new materials, go on courses, whatever. It’s easier to steer the course then it is to make waves. There are always reasons not to do something, but does that mean we shouldn’t do anything? Of course not. Let’s give our developers a moral boost. Let’s motivate them. Let’s make them feel important. Don’t stick them on shitty machines with small monitor/s.
Fuck it, where’s my new machine?
“It works 60% of the time, all the time!”
You can’t get a little bit pregnant. – Lou Mannheim
There’s a story about a manager that said his team was doing scrum/xp. When pressed as to the details of what that meant, the manager replied that they were doing ‘no documentation’. Scrum is the in project management methodology of the moment. Quality? Scrum! Clear deliverables? Scrum! Happy developers? Scrum! Pole dancing midgets covered in maple syrup? Scru… Hey wait a minute!
So yes, Scrum and what does it have to do with getting a little pregnant. My point is, if you’re going to do it, you need to go the whole way. It’s not enough to just dip your toes in the water. You may refer to your current load of work as a sprint, refer to units of work as stories and may even refer to your working capacity as your velocity. But, scrum is not about giving names to concepts, or about having a backlog, or having a burndown chart etc. Even if you did all of theses things together, you would still not be doing Scrum, because it is more then the sum of its parts. And I can guarantee you that if you start going down this path of faux Scrum, when things start to move slightly off course and panic starts to creep in, you’ll dip into your old ways to “fix” the immediate problems and then when the shit really starts to hit the fan, you’ll give up on it completely and deem the whole exercise a failure. That’s why you can’t get a little bit pregnant. You’ve got to go all the way and get to fourth base.
“Woah, Joe, all theses companies are succeeding with Scrum, we should do it too!”, “Yeah lets!” – High five! The product backlog gets written up, the burndown chart gets drawn and every morning there’s a stand up meeting with some people to discuss ‘work’. A week or two goes by and it really starts to feel like the wheels are greased and progress is being made. Then an urgent client request pops up, a massive bug has been found, or that feature they asked for two months ago and which they’ve just seen (Hey, we’re retrofitting Scrum to primarily waterfall driven project), isn’t what they wanted. Well the request is fine, we’ll go through the current sprint’s backlog with them and they can decide what they would like pushed back. Oh, they don’t even know what a sprint is, “What did you say? Spinelog?”. Well the bug is not a big deal, we’ll just run our tests, make the amends and get it sorted real quick. Oh there aren’t any tests. Ok well at least the incorrect functionality we can handle, we’ll just plan it into the current or next sprint and continuous integration means they can monitor the progress as we go a long. Spontaneous combustion? Fuck me. It’s not good enough to pretend, or for the development team to do it in isolation from the stakeholders or customers. To succeed you need buy-in across all the people involved with bringing the project to fruition. Everyone needs to understand the process and understand the role that they play. Pretending to do it ends up giving the team (mostly management) a false sense of security and that can really come round to bite you in the arse.
Don’t get me wrong, I’m not saying that doing Scrum in the above fashion is always wrong, because sometimes your circumstances leave you with little choice. But, what I am saying is that proclaiming to be doing Scrum without understanding it all the while living in blissful ignorance of the flaws of your own processes, is bad and harmful. I don’t mind mistakes or doing things the wrong way when you start out, because really you need to start walking the path before you can get to where want to be. I just can’t stand people saying their walking the path when really their just sitting on their fat arse, biding their time.
Man looks into the Abyss, and there’s nothin’ staring back at him. At that moment, man finds his character, and that’s what keeps him out of the Abyss. – Lou Mannheim
Investing in Your Own IT – The Ultimate No Brainer
I’ve been cursing my work computer all morning and am once again considering either bringing in my computer from home or just buying one outright (It wouldn’t be a first. I paid for my own monitor here at work. Go figure). Kris Kemper wrote a good post on the subject a few days ago.
I’ve seen this on every project I’ve been on. We are given slow machines, and time is lost. It may be lost because I’m running grep over a lot of files, it may be because when I have my all my development tools open and the machine slows down.
To me, when you’re in the business of developing software, investing in your own companies IT is a complete no brainer. Companies are normally extremely quick to spend on server hardware, but when it comes to development machines, spending is often few and far between. My machine here at work isn’t a “horrible” machine, but the agony it puts me through makes me feel that it’s perhaps not best suited to the task of developing on. But then even simple tasks seem to thwart it with constant disk grinding. I tried deleting an old repository checkout, no more then 200mb on the disk, and stopped it after it had only reached 14% done in 10 minutes. Virus checking my update of DirectoryOpus took nearly 3 minutes. Maybe it’s just a build issue and not so much a hardware one. Vista complains that all off the Office 2007 apps are not valid Win32 applications or the Snipping tool politely tells me it’s not working “right now”. Yes, I can see that. Whatever it is, it’s not the sort of shit that you need when you’re in the middle of something. Whatever, they should have got me a Mac.
I can understand that sometimes you just can’t afford whizzy machines or the latest version of software. Just don’t let me catch you running a .NET stack and complaining about not being able to afford machines fast enough to run it.
CSS Mastery
I have always hated CSS simply because anything I ever did would break in either Firefox or IE. I would spend countless hours tweaking and experimenting to get things consistent, and even then it felt like things where hanging together by a thread. Once things worked, I prayed I never need to “change” it. I have to confess that up until recently I still believed that tables were the solution to most web UI problems. A table here or there never hurt anyone. Really though, tables are sooooo Altavista. Thus, I’ve been making a conscious effort to move towards styled divs without tables full of spaced out cells containing transparant spacer gifs. I have been pretty much fudging my way through it so I thought I should read up on the subject and saw that CSS Mastery had gotten some really good reviews. I stole the office copy, made my way through it and can honestly say, with hand on heart, that it is an absolute must read for anyone involved in any sort of web development. My CSS ability has developed by leaps and bounds. I recently put together our new site which gave me a chance to flex some of my new found CSS skills and it made such a difference. Everything came together quickly and painlessly. For the first time ever I had a site that worked in both Firefox and IE pretty much off the bat and I had a tidy HTML and CSS file. Will this book make you a CSS Master? Probably not, I’m not one yet, that’s for sure, but it will get you on the right track to eventually getting there.
To go off on a bit of a tangent. Some work places have a specific team that do all the styling and formatting of whatever the developers give them. Maybe on huge projects, it makes sense, but in small teams I see no benefit apart from massaging the developers own egos and beliefs that HTML/CSS is beneath them or something. This divided approach really bugs me, simply because I believe that it causes developers to not give the asthetic or functional side of what they produce any consideration. Un-usable? Hey, it works and that’s all that matters, it’s not my job to make it look pretty! The process is circular. Good design begets good functionality begets good design begets… You get the point. Design is not just about making things pretty, and that’s the trap that people fall into. It is about communication; giving the user an experience they understand and can relate to. I’m not a UI guru or claim to have all the answers, but I’m a big believer in at least trying. The curse of knowledge from the book Made To Stick plays a big factor in this. People find it extremely hard, if not impossible to imagine not knowing what they know, and that is what stifles communication. I once argued with a company director about an existing system’s poor UI. They claimed that it was sooooo easy and quick to use and I pointed out that’s because had been walked through it so many times and used it nearly every day. So eat your own dog food and do your own HTML/CSS. Use your own system and pretend like you’ve never used it before. Do a hallway test and ask someone to perform a task without telling them how to do it. You might be surprised by the results.
Career Advice
Don’t know know what the hell you’re doing with your career? Read The Adventures of Johnny Bunko. Career advice in the form of a manga. Should only take you about 20 minutes to read (More if you’re slow like me).
Taking care of business
When you run a company that develops software, it makes little to no sense to lump your developers with sub-standard machines and tiny monitors. Managers who wouldn’t bat an eyelid at buying a new Visual Studio (Thank God I’m a Java/Groovy developer) license, gasp in horror and say there’s no budget when you ask for a faster machine or a bigger/dual monitor setup. Those minutes you save every day doing tasks add up to hours over a week, which add up to days over a month, which add up to maybe even a whole month over a year (in your dreams!). Personally, I’d just use that extra time to browse YouTube.
