If there's one piece of advice I could give ..

16 July, 2008

So I've been thinking about things, thinking about the state of web development. What could I write about to could help out some new recruits and budding developers. (Note this is a long one, so get some coffee, sit back, read, and I'd love to see your thoughts and opinions at the end ...). In a nutshell: I have a rather entrepreneurial friend back in New Zealand, he consulted at a Software company I worked for once. Over time we became good friends.. One day him and his business partner came up with a widget. And sold a few, and then needed to sell some more. Then one day he gave me a call. You can imagine as a web developer the conversation "Yeah some some company wants [insert horrendous figure here] to build us an e-commerce site" pffwaaaattt (coffee all over desk)... And so began a new relationship. Realising the scope of work was BIG, I actually called up one of my dev mates. "Oi, I've got some work for us, keen?" Gave him the specifics. We agreed to do it 50/50 (side note, later on I ended up taking it on 100%). We struck a deal. I drew up a contract and we got underway. It's one thing sitting at a desk job, saying something will work, and then meh, it doesn't, this happened or that happened, whatever the reason, your thing doesn't work. There's a kazillion reasons why something won't work, or can't be done, or is late etc. Depending on your character this will bother you, or not (hopefully the former!). It doesn't *really* teach you responsibility. Now, taking someones money personally, and promising delivery of something, with nobody else to shoulder the workload. Now that's responsibility. There's only you and your Mac/PC. So long as the two of you are both in working condition, and you haven't bitten off more than you can chew well there's no excuses. Everyone reading this should be familiar with the actual mechanics of building something, but most often you're shielded from the business elements. Why are you building what you're building ? Is some Business Analyst telling you chinese whispers. Do you really know ? It's all about the vision. This isn't some contrived management tactic, there's a reason people put it on the top of briefing/requirements docs, if you buy into the ultimate business goal, then you will be far better at doing what you need to do. There is a famous saying in New Zealand - "Make the boat go faster" an entire army of engineers, yachtsman, craftsman, tacticians were all about one single minded goal - making the boat go faster (and they did, Black Magic won the Americas Cup). In our case it was all about selling the widgets. By being both a friend, and supplier, you realise you're taking money from this company, your friend, to build something. They're going to have to make that money up by selling product. So, you'd better do what you can to help them sell that product. By keeping the vision at the forefront of your mind you're not going to use technology for technology's sake. You're not going to waste time spending 10 hours getting some little bit working when it doesn't matter. You are going to learn how to prioritise - especially if you're doing this in your hometime. Once you've wasted 3 evenings in a row and not gotten any further along the path to completing your objective you'll quickly learn what's important! This WILL make you a better developer. Too often I read posts about the top x number of things looking for when hiring a developer. Technical brilliance is IMNHO focused on WAY too much. By doing the process from start to finish, you'll realise, the minor technical bits are quite small in the overall scheme of things (unless of course you need to build some ninja fast product requiring complex calculations) Note as I've been writing this Ilya put up a great post mentioning the jelly jar, another way of looking at this issue You will hear and see a lot people who are singularly focused on one technology, one piece of the puzzle, they're specialists. That's great. But a piece of code, or a sql call, or a config file does not a web app make. If you have to do everything from ordering a server to getting the finished app up and ready to login, you'll realise there are a lot of pieces of the puzzle. By doing everything yourself you'll begin to realise the other side of the fence is not as nearly black magic as you thought it was. Gaining experience in all aspects, from server config, mysql setup, dns setup, playing with cron will make you a lot more well rounded. By becoming more experienced in different aspects, you'll realise you can do a lot more. [As a side note, this is also why I think working in a startup, is a damned good thing. Every dev should do it at least once!] Along the way, your client is going to ask you for things, lots of things. And you're going to have to manage that feature request cycle. Now who knows better - you or the customer ? The just say no philosophy that is becoming pervasive in web app development school of thought is scaring me. My client loves it when stuff gets implemented. I don't just say no every request. Where stuff doesn't make sense, or can be done better, I talk through it with them. But if I just said no everytime. Well the relationship not likely go far. Don't get me wrong, I see it's place, but you have to use judgement, and know where it applies. Don't take it literally. When you're close to the customer, you'll realise their daily pain. Walk through the system with them, understand every support request - what lead to it, why, what can you do better ? Now, why did I say in my opening statement maintaining an app. Long term there is no greater thing than maintaining what you wrote. In our day jobs, we move on, client's move on, the code moves on. But invariably the business doesn't - it stays there and so does the site. By maintaining something yourself you get an appreciation for the movement in technology(when we first wrote this app, the nearest thing to a published framework were the PEAR libraries, nobody had yet come up with a solid stack). Now 3-4 years later I'm rolling in Rails into the mix. You'll understand the value of commenting the tricky bits. it always comes up as a reminder, just last week I was all over some code questioning "WTF did I do here?" especially when the business decision hadn't been written down beside the code. Along with gaining a much fuller appreciation of clean, modular, readable and reusable code. Also you'll get the chance to refactor and it makes you (well at least it does for me) feel good. Some crufty bit of code you haven't touched for 6 months, and you get to make it look better and work better. Nice ! This might seem counter to what I've been saying. But I think this is how a lot of new technologies get adopted. People are playing on pet projects and attempt to use a new technology. Doing your own app, you get to make the choice. It's either going to work or it's not. And you have to live with the win's or losses. Whereas in your day job there might not be anyway on gods green earth you're going to implement technology x as the impact on a large team is huge, but on your own time - it's your choice. You get to play with jQuery for instance (whichs rock extremely hard by the way), or mix and match Rails and PHP. Can you imagine what a system architect is going to say when you propose that in your day job? No f-cking way. Of course, you have to pick your moments and rationalise why you're choosing that technology. What is it really doing better for you... This is where doing a project for yourself shines. I saw a great clip by Tony Robbins the other day, must say I've never seen him before, and not likely to buy his products, however he did say something that that resonated with me loudly - too many people blame the lack of resources time,money etc but ultimately their failures are not about lack of resources, but the lack of THEM being RESOURCEFUL. This is what I'm talking about with this post. Maybe it's a really long winded way of putting it, but by building and maintaining your own app, in order to do it successfully you'll have to be resourceful. You'll have to learn, prioritise, be accountable, responsible, problem solve, etc and it will all matter because.. You'll get this at the end of the day. That's what I appreciate in developers. People who when faced with a challenge won't back down. They will find different approaches to a problem. They will try and try to get something running, they'll go away, rethink the problem and have another crack at it. Once done, they'll polish it, make it look work better/faster/ etc to acheive the end goal/vision. Having done that they'll take pride in it and say "I did that, I think it's cool and it rocks, and here's why ... ". Going back to my original opening statement, doing a project yourself gives you the opportunity to do so, virtually unrestrained. You'll get a tonne of challenges from technical, emotional, financial, time, the whole gamut. But by taking on the responsibility to do it yourself, (or be responsible for delivery yourself - you could farm the whole lot out, then you've got a whole new set of problems!), it means you have to meet and break through each one of those challenges. The only constraints in general, are your time and motivation. A number of years down the track you can look back on it, and go 'damn that feels good' When I get the chance to interview people one of my questions is always Feel free to answer it here, I'd like to see what makes other people tick..

Read More

Good to Great (rules to live by)

31 May, 2007

What makes a great developer ? Outside of obligatory technical and problem solving skills which go without saying, the differentiator between good developers and great developers I think simply boils down to understanding, empathy and respect for your client. Having a cross functional developer that can write code and talk to a client in plain english is an amazingly huge (and seemingly rare) asset to any team or studio. As the world slowly moves away from waterfall development I think this is going to be increasingly important. I've worked with the uber algorithm generator russion rocket scientists, the fresh out of university bumbling junior guy, the know it all with an ego the size of africa, the one that wants to debate every minute detail until they forgot why they were debating it, the one that will fight to the death to not change the feature they just implemented. Every time the one developer that's stood out, and had clients want to work with them, were those that sat down and understood the business problem at hand and were empathetic to their clients needs. If you spend those hours/days up front and actually listen to your client. Put yourselves in their shoes, and understand how they do business and want to do it better. You are going to go a lot further than those who tell the customer how to do business. Here's my rules to live by: 1. Mr/Ms Pleasant. It doesn't matter what business you are dealing with, people unless they like being antagonised, will actively avoid dealing with an unpleasant person. I have a bike store by my house, it's got everything, it's convenient, but if I have to deal with the mechanic once more.... so I use the bike store close to work. Inconvenient, pain in the proverbial, the kids are way less experienced but I'd much rather deal with an 18yr old kid who's eager to please, than the 40 yr arrogant sod who has no time of day for you (I have no time of day giving him my hard earned cash). I'm sure we've all had those experiences no ? Now multiply that $50 purchase in the bike store a good 200-2000 times into a big scale web project. Who's the customer going to pick, Mr/Ms Pleasant or Mr/Ms Arrogant. 2. Mr/Ms Understanding. Understand the business problem at hand, and make an effort to understand the wider context of the business. Don't try and get the full story in the nth degree on the first meeting - you'll be there for days, however everytime you meet again, always try to get a bit more business knowledge in the wider context of the business. The more domain knowledge you have about the customer's business the easier it makes your job, the more valuable you become. 3. Mr/Ms Talker. Talk with your customer.... just because you and everyone around you uses email for everything, it's not necessarily a good thing. You get so much more out of talking and more importantly listening than you ever will on email - the hesitant pauses (.. maybe not a good idea to work on this functionality, they're unsure), the excited yes please (.. get it delivered straight away they want it!). I tend to talk or meet face to face, then follow up with an email restating the items to be actioned, priorities etc. Everytime I've relied solely on email it's been a disaster. And with any important business dealings (ie you get the contract, you've been paid, major milestone etc). Talk on the phone then follow up with an email - it shows respect. 4. Mr/Ms Restater. As part of number 3, to show your understanding of a problem, always restate it, multiple times if need be. It's like learning your ABC's. It a) shows you know and understand it, b) gives the customer a chance to rethink it through, see if it makes sense. Use role play "Okay, so I'm your business store owner, at the start of the day I go to my computer, fire up the browser, go to... I'm the region manager, at the end of the day I do..". You've got to have personal confidence of knowing the problem and your customer has to feel happy you can go away and put together a solution. Nothing's worse than giving a task to someone who has that semi nervous 'yeah.. sure, okay, i'll be back in touch'. I rarely need to refer to notes as I make an effort to understand the problem. 5. Mr/Ms Light. Don't go dark. No matter what.. don't go dark. It's the standing joke of feeding the pizza under the door and waiting for something to come out the other end (and waiting.. and waiting). The customer gets worried, you go off on a tangent it all turns to custard. Keep in touch. Even if it's just an email 'Just to touch base I'm working on aspect x. I expect to have it sorted in 3 days, I'll send you a screenshot then'. It also keeps you top of their mind, and them top of your mind. 6. Mr/Ms Nicely No. Say no carefully. If something's a bad idea, no with a smile and say why you're saying no. Remember Mr/Ms Pleasant ? ... The customer is paying the bills so be careful with this one. The customer is always right can be rephrased as: The customer is nearly always right in terms of what they want to acheive - but doesn't have experience in execution so often need to be guided. 7. Mr/Ms Goal Oriented Understand the stated goals and objectives. Extract these from the client before you run down the path of looking at the functional elements of your task. If you don't know what you're trying to acheive how can you write the steps to get there ? The customer often will express what they want by how they want to acheive it e.g. "add this button here, make it go to this page, then ask the user for this" vs "We want the user to give us their address information before entering the site" 8. Mr/Ms Humble Know when you're wrong, face up admit it and move forward. Unless you're facing a law suit then talk to your lawer don't listen to me! It seems obvious but it's the hardest thing to do, especially the later in the game it gets. Finally... Remember you're an expert in your field, they're an expert in theirs. Respect, understanding and an empathetic relationship will take you a lot further with your dealings, and will help to garner you more business and referrals. The cool toys like Flex, Rails, Ajax, etc all just help you along the way. Be the dude/dudette that either a client, or a project manager says "This person is fantastic, you should work with them"

Read More