Well, it's been a busy couple of weeks. I've been interviewing and code-testing and otherwise rushing back and forth like a headless chicken...
But it's all paid off, and I have myself a new job, starting Monday. I'll be working at a company in Crows Nest that specialises in software for the employment industry.
I'll be coming in at a senior level as lead developer, building one of their four main products, assisting Registered Training Organisations keep track of their students and courses.
This is actually a really interesting point.
13 years ago, the Cluetrain Manifesto loudly told us that we should actually (shock) listen to what our customers actually have to say - even the complaints - without trying to pretty it up for the ears of upper management. It led to companies really listening to their audience and being able to build products that addressed the real problems of their customers, rather than wasting time building solutions for some idealised pseudo-customer.
Lo and behold - the customers loved it.
Is it time we started listening to our employees the same way? Everybody has a grumble or two. But rather than everybody pretending they don't exist, and hushing them up the moment they try; perhaps it's better to create an environment of openness. One where people are not afraid to talk about the things that aren't working.
If we are prepared to really hear what somebody else has to say, even (or especially) if it's negative; then we have a chance to actually address the problem and make it a better world for all of us.
Sounds like a win-win to me.
There is well-known a skills-shortage for programming... but don't be fooled. There are a lot of programmers out there too. The skills shortage is about there being a lack of *good* programmers. Just rocking up with a bright new CS degree is generally not going to cut it for you. You'll just have shown up at the door along with the other thousands of new CS graduates in your city this year. So what can you do to stand out from the crowd? To prove that you are, in fact, worth being in demand? How do you build a reputation as somebody worth hiring?
There's no quick answer to this, but there is a reliable one:
It takes work.
It takes both time and effort - and the earlier you start, the better. Yes, you can (and should) start before you graduate (if possible). If you wait until afterwards, you'll be in the same pool as everybody else, hoping to be picked while you scrabble to make your resumé presentable. But if you've already been working on your reputation, then you'll be able to hit the ground running - and walk into a job as soon as you're free of university.
If you've already graduated (or you're not going through the higher-education system at all) don't worry. You can still do a lot to improve your rep - and the earlier you get started, the better you'll be.
Obviously, what you need to do will depend on your exact circumstances... so take what I say below with a grain of salt - as just one person's brainstorming session. Then figure out what you think will be good for you and just start.
Lots of places advise you start a blog... and they're kind of right. But if you're just starting out, you probably don't know exactly what to say yet. If you're just bursting with great ideas you can share (and I don't mean updates on what your sister said to you last week, or how cute your cat is), then great - go for it. A blog is a good way of showing the world you have something worth contributing... but be warned that a blog is not a get-hip-quick scheme. It generally takes about 2 years (minimum) to gain traction.
Sure, there are some notable exceptions - but they are very much the exception. Just like hundreds of attractive women coming to hollywood in the hopes of instantly becoming a star - thousands of new blogs get started in the hopes of becoming instantly famous... and most of them end up with the blog equivalent of a regular, average acting career after doing hours of work playing the dead body or acting super bouncy in hemorrhoid commercials.
So yes - start a blog if you like... but don't let that be your main focus just yet.
My best recommendation for you would be that you start out by actually coding something interesting.
Having a github account is an extremely useful recruiting tool. Much better (to the people that matter) than a plain-ole CV. You can actually show people your real code. Given that this is precisely what employers are trying to hire you for - it makes sense to have some available for them to see.
What's so interesting is just how few candidates actually bother to have any code samples at all... Most employers have to try to guess at how good a candidate really is by asking obscure technical questions - which are a second-hand guesstimation at coding ability at best. If you've got some actual code they can look at - it solves one of their biggest problems (ie whether or not the person is lying through their teeth about their programming skill). Even if your code isn't the world's best... and employer can accurately gauge your real ability... comparing that to the chance that a smooth-talker might be lying about what he/she can do, this is still a net plus.
Figure out something that you need yourself, or think would be cool to work on. It doesn't matter if it's been doe before - you're having a go to see how well you can do it - and show off to other people too. Yes, writing games is perfectly fine - it's how a lot of people get started, because it's fun as well as useful.
If you can't think of something yourself - have a look at the open source projects that are already out there. If you already use something (whether a tool or a game), go have a look at the code (it's free), look at the list of bugs for it (every project has one of these, though you may need to email the project owner to get a copy) and have a go at solving one of them. Then submit the code back to the project.
Another idea (if you still don't have any yet) are puzzle sites. Eg Project Euler or ruby-quiz. Work through them every week and see how far you can get. It'll tone up your problem-solving skills as well as building a back catalogue of code samples to throw at potential employers to show your mad skillz.
Having a ago at a startup shows initiative and sticking power as well as all the other skills such as marketing ability. It also gives you valuable experience in the essential skill of "listening to what customers actually want"
If you have a cool idea for something you can build - try to find some like-minded friends who also want to build something, and team up. Extra people can help lessen the workload (allowing you to do more cool stuff in less time), or can flesh out areas where your expertise might be lacking (eg working back-end code if you're mostly good at front-end stuff).
Most importantly, though, is to just have a go at building something... and then shipping it!
It almost doesn't matter if you fail at a startup. You'll either have a) a product that is selling and making you money or b) some incredibly useful experience at working in a team with others and trying to get a product out to a market. As long as you aren't hocking the family home to pay for it, you can't lose.
If you don't have any like-minded friends just yet - I suggest going to hackdays and startup-weekends. A great example is launch48 - where people who want to try startups gather, and you get together to build one over the weekend. If that isn't near you, google for "(startup OR entrepreneur) internet" and your city and see what's nearby. You can also checkout the local internet entrepreneur groups in meetup.com. Finally, you could checkout MatchFounders to try and find like-minded potential-founders.
I'd also strongly recommend Stack Overflow - a question-answer help site for programming-related questions.
Solving other people's problems is a good way of showing you know your stuff. Even better is that you don't need to start with experience to help people out. There are a lot of newbies that post questions to S/O - and you may well have simply better google-fu than they do. Look through the latest-asked questions and see if you can solve any of the problems yourself by googling the answer. Then put an answer up. It doesn't matter if you're the first-answerer, as long as you get the answer right. If what you find out is helpful - you'll get voted up and will be literally building your reputation. If you get voted down - try to figure out why and do better next time. If nothing else - you'll have learned something new, and over time you'll learn the important art of effectively explaining things to others.
Only now, once you have been working on other things for a while, should you start a blog. Now, you'll have something to say...
If you don't have a particular idea for your blog, I recommend you start out by blogging the solutions to problems you have in your other coding. This is a bit like Stack Overflow (and I recommend you submit your problems to both). However the approach you use on a blog is different to what you use on S/O. On S/O it's all about "here's the problem" and "here's the answer". A blog post is about the journey. How did you come across the problem? Why was it a problem for you? What did you try to solve it? How did that work out? People want to know about dead-ends too - as they want to know what to avoid if they find themselves in a similar situation. What finally worked? Who helped you? If you got help from somebody, or found a tutorial online - a linkback to them is a great way to give back.
So as I said - this is just my own personal brainstorming session, based on one person asking me about it... I'd love to know about other ideas for building online reputation. What worked for you? What have you heard working for other people? What did you try and backfired?
An old guest blogpost on RailsInside caught my interest, called The perils of opinionated software like Rails. It's never a good idea to get too fanatical about one's choice of framework - so I definitely recommend having a read.
He raises some good points, including the should-be-obvious "the opposite of bad software is not necessarily good software". The specific ideas he raises are surrounding Rails' poor re-implementation of database security-checks - something that old, enterprisey-style applications leave up to the actual database, because that's been a solved problem for years. Recent versions of Rails are better at this, but I think his message is still important. We should always keep in mind that old enterprisey software may still have some good stuff that we maybe aren't using more through fear of looking enterprisey ourselves, rather than because it's actually not a good idea.
So, after a trip to Thailand, I'm finally back home in Oz and ready to look for a new role. Here's a quick overview of what I'm looking for, and what I've done - get in touch if we match up
I prefer building meaty applications solving interesting problems. I'm not interested in building cookie-cutter brochure-ware. I prefer greenfields development to maintenance work.
I like to work with agile teams - sprints and kanban is good. I do not enjoy pair-programming, so if that's your style... maybe not for me.
I prefer a relaxed and friendly culture. "enterprisey" corporations need not apply!
I tend to find that the "standard" recruiting tool of the Word-doc resume does not accurately reflect my skills, so here's a list of my work and my presence online in the technical sphere. Go have a look for yourself.
LinkedIn has the closest thing to a resume. This is my profile page on LinkedIn
You're currently *looking* at my technical blog - showing my howtos and code snippets etc
I have a WorkingWithRails profile.
I have a StackOverflow profile.
I have a github account.
There's no recent work in github as I've been traveling a lot this past year, but you can see the patches I submitted to rails core (for Rails 3) - which centred around my work on the HyperActive Resource gem, which I was converting to the core Active Resource code.
I led a team building a startup website (called Matchfounders) back in Sep 2010 over a hackday weekend (called Launch48).
After the weekend, I took the prototype (in PHP) and rewrote it in Rails 3 (adding such trivialities as a test suite and actual security measures)... then developed it a *little* bit more. It's not currently under development but go have a look to see what I can do in about a week's worth of work.
Not immediately evident from the above, but I was active in the RoR oceania community in Sydney before I left Sydney, as well as SLUG - where I gave a howto talk on Rails about four years ago.
When I went to London I was active in LRUG (the London Ruby Users Group), also giving a couple of talks, one of which is online here: Rubyprof and kcachegrind
I briefly featured on a peepcode podcast, interviewed by Geoffrey Grosenbach about my work on HyperActive Resource... but I'll admit I was somewhat overawed and didn't come off sounding particularly clever.
Last and most definitely least I have a website... but it is the neglected poor cousin of all my other sites and is not worth looking at
(*cough* not updated since I left Sydney three years ago *cough*)
I'm an experienced senior Ruby Developer in Sydney - looking for a position in a solid company doing cool things. Drop me an email at this email address
Following from are women in tech really in tech we have:
Some things to think about before you exhort everyone to code by Miriam Posner
Which points out the important cultural aspect of why it is that women are often not coders.
If you are not a woman in tech, and wonder why there are so few... this article is for you.
So is this recent article on the recent "brogramming" phenomenon: Brogramming: just one of the girls by addabirnir from Skillcrush
She points out that "brogramming" has its intentions in the right place: it is just trying to inject some appeal into coding... but is doing so in a blatantly misogynistic fashion. (eg "without brogramming, bros might just feel like...one of the girls") and thereby alienating the very few women who are trying to break into this industry.
The important take-home message from her is "you don’t need to alienate anyone to make yourself comfortable"
Also of very distinct interest is the NYT article about Wikipedia's serious gender imbalance, which also points the finger strongly at geek culture - which is extremely male, and can be very uncomfortable for a woman.
Speaking personally on this subject, it took me a good ten years before I figured out the rules for getting along in geek society. My feminine upbringing was with an entirely different, incompatible culture. I can well understand that the serious culture shock would be offputting to the point where many women might not even want to bother continuing.
Again, I'd recommend reading all these article to get a glimpse into why this is the case.
A post inspired by 1.00 FTE:
Makes the obvious point - any truly bad behaviour should be addressed specifically with the given person. Otherwise you end up with gargantuan employee policy documents filled with items best left to local law enforcement.
The question then becomes, where to draw the line? I also think we can apply this principle to the grey-areas - the smaller infractions that, if policies are created, become annoyances that the rest of the staff must deal with.
I've been here before... company-wide policies on email, facebook, draconian time-clocking... generally only instigated when some young intern has done something stupid, so everybody else has to suffer for his/her bad behaviour.
Sure, if somebody abuses your trust then punish them, or fire them, or put them on probation or whatever you need to do. but changing a policy for the entire company is overkill. Especially when it degrades the previously open and enjoyable culture that you spent so many years developing.
Don't let the actions of a single individual degrade the trust that you give to your other employees. Trust is hard-won and easily lost, for sure... but it's also an essential component of a happy workplace. People don't want to be treated like they are children - and will find it stressful to be constantly nannied when they are capable of looking after themselves.
With a nod to the fact that some people *do* need supervision, try to trust your employees to at least act like the adults they are. After all - people try to meet your expectations... whatever they are.
Blogger is doing a most unkind thing with profile pics - it scales to fit and does not respect the aspect ratio.
I've updated my profile pic to match the "acceptable" ratio on the full-size profile page (FYI everything is scaled to 140px wide and 180px tall). Previously it was stretching it width-ways and making me look like the fat-mirror in the hall of mirrors. :P
Of course my profile pic is a few years old now... but still close enough to life for people to recognise me, and I'd like it to stay that way.
Jeff Atwood (of CodingHorror) recently left StackExchange after four years of really hard work. He gave his reasons in a farewell to StackExchange - explaining that he has realised that, as amazing as it is to work on a brilliant project... it's not worth missing out on your children.
To this I'll add a recent Ignite talk: Go the fuck home by Pam Selle
I totally agree.
Anything over a 40 hour week is really stupid. Not just for you, but also for the business you're working for. Many good books have pointed out that, not only do you not do your best work after five... but sometimes you can be actively sliding backwards (making more bugs that have to be cleaned up).
Of course the business won't say no. They think they're getting extra work from you for free... But remember that old deathbed adage about nobody feeling like they should have spent more time at the office.
Don't ever forget that any extra time at work is at the expense of your most precious commodity - your own life.
You only have one, and it's shorter than you think.
Get Real about how you're spending it.
You really don't win anything by giving it away for free to an employer that *maybe* might pat you on the back and give you a tiny pay-bump when your next review comes around.
yes, some companies are amazing, wonderful places to work for and you truly enjoy being there, that's great.... but this is the exception, not the rule, and even so - think about Jeff Atwood. StackExchange really is one of the really amazing places... but it still isn't Your Life (the only one you've got). So really think, then think again about your priorities here.
I know what it's like. Your boss tells you that it's critical to hit the next deadline and all but orders you to pull an allnighter? You do know they actually cant enforce that don't you?
Afraid you might lose your job? yes, you might... and then you might go find one where they treat you like a human, instead of a "business resource" to be pushed around at will.
Again, unless you're in a rare position, you probably aren't building the cure for cancer... and that deadline, while it might hit the company's bottom line today, probably won't cause people to actually die if you miss it... but what will happen is that you will continue to prop up a company that has very poor planning skills - and that is willing to exploit its workers at the expense of their time, health and sanity... and you're helping them do it?
Go the fuck home!
Finding good "help" is always tough. When your help is located thousands of miles away in a country where english is a second language... that can be even tougher. How exactly do you filter out the dross and find the diamonds?
C42 have just put up a really interesting tutorial on how to identify offshore ruby on rails vendors that don't suck. I've never outsourced myself, but this looks like it would be a good starting point.
Anneke Jong has posted an interesting article called why we need to rethink women in tech, which points out the real reason for the seeming disparity in numbers of "women in tech" comes about due to the definition of "in tech" being used.
She explains that while several recent articles are applauding the increase of "women in tech" - these numbers are gathered from women who are, in essence, working in tech-adjacent roles (eg marketing and PR for IT firms, or tech-bloggers such as herself), rather than actually having coding skills - which would be the definition of "technical" for those working in the industry.
As a coder-girl myself, I can see her point. There has indeed been a great uptake of "women in tech"... but the increase of actually technically-competent women is much slower.
While the figures quoted in media seem good at first glance - they aren't telling the full story of the gender imbalance. Anneke makes a great comparison with the music industry: "Imagine your disappointment if only a third of the 'Top Women in Music' were musicians."
This is not to say there has been no progress over the last twenty years. When I began my Comp Sci degree, I was one of only seven women in a class of 220, which was no uncommon at the time - whereas now the proportion is closer to 1 in 10... but that is still a far cry from 50%
The article, of course, offers no solutions - because generating interest for computing (or maths, for that matter) in women is still one of the Hard Problems facing education... but it's a good discussion of the problem, and worth a read.
I made it to the AllTop ruby feed.
Apparently this is a big deal? They even have badges (see my ever-growing pile of badges at the bottom of my left-nav).
All part of my recent bout of SEO link-building experimentation in the last few weeks.
An interesting point here that is quite true. Effort isn't enough... however - is it really possible to compare groups of IT guys against "industry average"? What data do we have on "industry average"?
Have we gathered reliable data on any of these? How would be go about collecting it and is it even really possible to do that reliably?
I guess it's possible if you're doing work that's already been done (eg building a better mousetrap)... maybe if you're churning out cookie-cutter brochure-ware websites perhaps? Or Yet Another Spreadsheet App?
Even so - I'd be curious how you'd determine the productivity of other groups in your industry - what is it exactly that we're averaging? Time to complete features? Code quality? Lines Of Code? :|
Even if we decide on a metric, asking people in your own company about their past experiences will only give you a few datapoints - possibly distorted by 20/20 hindsight (or whether you want to come off looking better than reality might show up). I don't know of any reliable info out there apart from this kind of self-gathered stuff.
How do we go about gathering data across companies and how do we trust that data? It'd still be self-reported and therefore open to various forms of bias ("Yeah, my *old* team used to be awesome! nothing like this group of idiots!"), differing levels of slave-driving ("Yes, *my* team got it done in a week... just ignore the shackles on their legs!"), differing levels of quality ("we got it done over a weekend! security? testing? what's that?") and downright manipulation ("yeah, we're Team Awesome and can code up a custom-built website in only 24hours!!!!")
Not that it wouldn't be worth giving it a go.. but of course you still fall back on the problem of metrics. What metrics reliably indicate productivity (especially when we need to hold code quality constant)?
"Features" produced per week perhaps? but what is a "feature"? how big is it? how do we compare across companies and even across industries? It's a tough call - made even harder when you add the "quality" constraint. Is a cavalier team churning out unplanned, untested code full of security holes *more* productive than a careful one that designs something elegant and simple, robust and well-tested?
Measuring quality is always a tough nut to crack.
I've seen people try for "customer satisfaction" - but in our industry, it also pays to ask "which customer?" - the one paying the bill or the one that is forced to actually use the product? Another example of Who is the real user here?
So... are there any resources out there? and what's people's experiences of their quality?
Who should learn to program presents a brief look at the reasons why everyone should learn to program, and also a very good reason why not. Worth a look.
A fairly standard question on quora: Why are software development task estimations regularly off by a factor of 2-3? has sparked some discussion.
The best answer given was an extremely entertaining hiking analogy (it's the top-voted answer - go see), explaining the software development process in terms of the fractal-nature of a coastline, with unexpected delays along the way.
I think it's a great analogy as it goes and would be extremely helpful in getting the idea of unexpected scope-creep across to a complete IT-newbie.
The answer then spawned a plethora of comments and even a counter-post that is also really interesting: Why Software Development Estimations Are Regularly Off, which explains that the hiking analogy is way off, and that software estimation is more like inventing.
I agree... though I still see great value in the hiking analogy for explaining "what goes wrong" on the kind of project that encounters the problems described.
The counter-post has itself sparked a discussion on Y-combinator which goes into a lot more detail about estimation issues in general.
It's all provided me with an entertaining read on an otherwise well-picked-over subject.
OMG how much do I love this oath!!!
I might put it in my standard contract going forward :)
Just a quick post as a follow-on to my project Euler post a while back.
Project Euler have had a site revamp. A bit of a nicer UI prettier progress-tracking and addition of merit-badges to mark some interesting milestones along the way.
The fun is still in solving mind-twisting math-puzzles... but it's at least nicer to look at now ;)
The hungry programmer compares healthy eating to healthy code-practices, discussing the code-quality equivalent of the "healthy eating continuum". In brief:
If you take the McDonald's approach and ship shit then you satisfy that need in the short-term. But you'll feel the effects in the long-term. Your code will be harder to maintain and need more attention later. It won't have a long and healthy life.
I know there have been several times when we just *had* to ship *something*... no matter the guilt I felt at the poor quality that was going out the door. I much prefer to spend some time *now* and work at the better-quality result - even if it means "going hungry" for just that little bit longer. Still, I also understand that a business has to ship to remain a viable business... It's one of those universal dilemmas.
What experiences have you had? Any spectacularly difficult trade-offs you had to make?
It's fairly old, but this is still a good basic reference to SEO and link-building
Just be aware that IPL2 is no longer accepting link submissions. You have to register as an editor for joeant to be able to submit to them (which is free, and you don't have to submit any other links, though it helps).
This one also has some good ideas:
How to build links fast
...and some hilariously dumb ones at the end (including "sue google" and the RIAA technique). :)
Anybody have any more recent good tutorials on link-building?
A post inspired by 1.00 FTE:
This is a bit of an aha moment - I'd especially recommend reading the comments about what happens when the perceived capabilities clash.
I have left a job where my perceived capability was well below what I later found out to be reality. I definitely experienced a chafing-at-the-bit (or perhaps "crushed-beneath-the-boot") sensation at that workplace. I was constantly irritated that the mid-level manager didn't seem to trust me to do my job.... even when I tried valiantly to prove my capability, eventually bringing about a revolution to their help-desk system for which I still occasionally receive praise (six years after I've left).
Perhaps the manager was right - perhaps I wasn't as good as I thought I was... but given that I literally doubled my income when I walked out the door (and haven't looked back since), I doubt it.
I recognise it's difficult for non-IT-front-line bosses to accurately gauge the skill of their techies (see my old article on The economics of IT salaries for a discussion) but it's still not good when this sort of thing happens.
That being said - there is absolutely a real need to provide direction for those that need it, and to make sure that everybody's on the same page. So... what to do?
Is it better to downgrade everybody's skill level to make sure nobody incompetent accidentally gets through and influences strategy until they've "proven" they are capable? Or is it better to trust first?
I'd go for the latter... mainly because I agree with the old adage of "people will meet your expectations whatever they are"... but then I don't have to pay the bills. Opinions?
