September 28, 2010 § Leave a comment
My first foray into the post-college workforce involved time spent answering the phone and helping people use a Windows application. Of course, there were the “other” calls as well – since I was “technical” I could solve any issue with your computer/network/email system, right?!
This was soon a programming job that included training customers on the application I worked on (with someone else taking the calls – thank you thank you thank you). This was an eye-opening experience, and it made the work I do so much more rewarding. After all, I was able to see first hand how I made the work of other people easier and more enjoyable. I’ll never forget being on an elevator after finishing a training class and hearing a customer described what was once a mundane job as “fun”.
And… of course, the opposite is true. Ever seen a customer use your application in a way you never intended only to bring your app to its knees spewing errors and leaving the customer banging the mouse and going on yet another coffee break? No, that’s never happened to me, but… yeah. It’s painful and again, so enlightening and here’s the point – important.
In both instances, as a developer I was there to witness the joy and the pain of something great and something bad that I had brought into existence. What did I learn? That better apps are built when you understand for whom you are building and even better apps are built when you can see the customer use what you have built. That said, this is definitely better done beforehand with wireframes and prototypes.
I know my experience is somewhat unique – not all programmers like to wear multiple hats and not all companies like to (or see the value of) putting their programmers so close to the customer. So how do we build empathy in those developers who are walled off from their customers? We could build personas that as accurately as possible represent the customers. We could find a willing customer or two to share their experiences in person and/or in writing with the development team. We could host a meeting of the minds where select customers and developers are able to cross pollinate ideas and give feedback in a casual setting.
Any other ideas?
February 7, 2010 § 3 Comments
Seth Godin is one of my favorite bloggers, and his latest book “Linchpin” is on my list of books to read. I almost always agree with what he writes and walk away inspired. Yesterday he posted this on his blog:
The relentless search for “tell me what to do”
If you’ve ever hired or managed or taught, you know the feeling.
People are just begging to be told what to do. There are a lot of reasons for this, but I think the biggest one is: “If you tell me what to do, the responsibility for the outcome is yours, not mine. I’m safe.”
When asked, resist.
The following morning (today), it had been retweeted 440 times and my Google reader tells me that 60 people actually liked it.
There are many people who actually need to be told what to do and not because they are trying to shift responsibility. Thankfully, Seth acknowledges that there are other reasons why people need to be told what to do, and I will not go into those here (ok, maybe one reason). I disagree with Seth in that I don’t think this is the biggest reason.
I’m not a manager, and I haven’t hired anyone. I have done some mentoring and have been a lead developer on a couple of projects. Drawing on that experience, people programmers need to be told what to do for a few different reasons:
- They lack experience.
- There are so many choices in terms of tools in what to use in developing a solution. “Telling a programmer what to do” helps create consistency in a project making it more maintainable.
- Programmers often get overly excited about learning new technologies that they will use the new technology even when it isn’t appropriate to the solution.
- Development efforts, especially in large organizations, need to adhere to an architectural vision and a set of tools and frameworks. Without this “telling what to do” you have skills, software, and programmers running amok creating technical chaos that results in a hemorrhaging of cash with little of quality to show for it.
Knowledgeable technical leadership is invaluable. Self-motivated people like me crave it because it better enables me to create quality software that matters, that won’t be scrapped in six months. Organizations benefit because it saves money, minimizes frustration, reduces time spent on throw-away code, and technically enables the marrying of multiple systems to be done more easily and efficiently.
January 3, 2010 § 2 Comments
My Own Top Five Technical Goals
1. Diversify! It’s time to put some energy into some new projects.
2. Learn something new. This list could be one of its own. At the top of that list would probably be mobile development. I have plenty of good ideas. Time to execute. There are also a lot of new .NET development tools I’d like to get my hands on. I want to read more on design methodologies, web 2.0, and usability as well.
3. Get some real agile training and learn how to be a better lead on a development project.
4. Seriously consider starting my own business. I was really encouraged by a recent post from Jason Cohen. Part of this consideration process will be to educate myself more on startups.
5. Find a way to fund some or all of my Top Five Gadgets I Cannot Afford But Want Really Bad.
Which leads me to…..
Top Five Gadgets I Cannot Afford But Want Really Bad
1. A Droid.
2. An iPhone.
3. Either a tablet (iSlate?) or a netbook. In red.
4. Wireless speakers to play internet radio throughout my house.
5. A Garmin watch.
December 23, 2009 § Leave a comment
Alan Cooper hits the nail on the head when he compares programmers to “normal people” in “The Inmates Are Running the Asylum”. We trade simplicity for control (we’re by nature control freaks), we sacrifice success for understanding (isn’t understanding a major part of success?!?!), we often put so much time and effort into what is possible that we lose sight of what is probable (we’re card-carrying pessimists), and we act like jocks (if you can’t mentally keep up, get outta the way!).
These traits in moderation make us excellent programmers. In excess though, a pessimistic, control crazed, mental bullying, tunnel visioned code monkey creates an endless money pit with nothing usable to show for all her exhaustive efforts.
The trait of particular interest to me is the desire to understand at the expense of success. It’s more than a desire – it HAS to happen! If I don’t understand how something works, I am reluctant to trust it. When I build a complex system that works beautifully, I am always astounded by the fact that users don’t want or need to know exactly what is going on to produce the final result. It’s satisfying when they do – running through the data to find the end result is correct (pat on back).
Success may be traded for understanding especially when a good programmer embarks on using a new technology – especially those which encapsulate a lot of complex functionality. The failure comes in when too much time is spent at the wrong time trying to understand these inner workings before using them in a project. A better idea would be to gain a basic understanding during the technical design phase or earlier. If a doctor is considering using a new laser-guided instrument to repair an eyeball, she will attain training using that instrument prior to the first operation. However, if she spends too much time trying to understand how the instrument was built, what makes the laser red, etc. then her patients lose out on a proven treatment and there may be a new and better instrument by the time she comes around to fully understanding the old one.
December 23, 2009 § Leave a comment
Being a programmer and a woman does not better enable me to design more user-friendly, intuitive technology. My higher estrogen levels also do not make me more creative. Oh, if it were only that easy! After all, the training and experience of most programmers is probably very similar. In Alan Cooper’s book, “The Inmates Are Running the Asylum” (highly recommend), he describes the conflicts of interest that exist when a programmer is tasked with doing real design and how our training (and sometimes inherent traits) make us good programmers and bad designers. In a time where companies are cutting costs and people and requiring more from each employee, many programmers are tasked with doing all the design work. Most of us enjoy it – I do. I like the creative process. However, given my training and background, self-referential design does not always provide the best result. Alan Cooper is the father of a design process called “Interaction Design”. Joel Spolsky suggests “Hallway Usability Testing” (note to self – don’t grab another programmer for this task!) and using the “Five Why’s”. Our training makes us better designers, not our hormone levels.
So, why do people make such a big deal about women in technology and there not being enough of us? How would the industry and the products we create benefit if there were more women involved? It’s the same thing that gives all of us the ability to bring something unique to any creative endeavor – the collection of our experiences. Experiences big and small set the framework for our decisions and color the lens through which we view life. As a woman, I am more likely to have spent time doing tasks typically done by the woman of the house. I manage the kids, the shopping, menu planning, finances etc. As a programmer and technology enthusiast, I am always on the lookout for gadgets and websites which help me do these tasks and others more efficiently and make it more fun. The true under-tapped benefit in getting more women into technology is in innovation. Knowing what technology is available, having the know-how to piece it all together, and looking at a problem from a woman’s perspective can lead to more products and services that help solve problems typically experienced by women. We can create more solutions that makes doing these tasks delightful.