I've been digging around in the computer programming job market lately, looking for programming job openings for all sorts of job skills. I started with PHP, LAMP, and CakePHP jobs, then dug into Java developer jobs. Today I took on a more difficult task: Trying to find "Scrum jobs", i.e., jobs related to the Scrum Methodology.
I've learned something about myself the last few weeks that maybe I didn't know before. While I don't like being tired, these last few weeks have been very trying, with long hours and hard work. The thing that I've learned is that this actually helps me to settle down, and focus on one thing at a time.
(From an email I sent to one of my clients regarding our software project.)
Last week we left the meeting with an open item to have [CUSTOMER_NAME] IT staff work w/ [DEVELOPER_NAME] to understand why some programming changes are easy, and some are not. More specifically, I think the question pertained to times when an application works one way in one part of the application, and then a user would like to see that same behavior in another part of the application. The question was something to the effect of "Why isn't this easy?"
A friend of mine mentioned something the other day that has resonated with me quite a bit. I don't remember who he was talking about -- a person in the military I think -- but he mentioned that this person went through interesting lengths to remind himself each day that we see the world through a narrow lens.
For some reason I didn't work w/ the Mac much until last year. Actually, to be fair to myself, a lot of that probably had to do with unpleasant experiences with earlier versions of the Mac OS.
But as I was talking to a co-worker this morning I realized that it was a mistake not to spend some quality time with Mac OS X when it came out. Having worked with it for over a year now I've come to take many things for granted that it can do. The discussion this morning had to do with the power of scripting native Mac applications with AppleScript.
This article is now part of my new eBook, which is only $2.99 on Amazon.com:
I hope you enjoy my book, and more than that, I hope it helps you have a very profitable and rewarding career.
This article is now part of my new eBook, which is only $2.99 on Amazon.com:
I hope you enjoy my book, and more than that, I hope it helps you have a very profitable and rewarding career.
A long time ago -- 1991 to be exact -- a friend of mine named Joe was a contractor for the aerospace company I worked at. Just like a consultant, Joe was paid by the hour.
At some point Joe decided he was going to leave that company to take a permanent job elsewhere, as he had a medical problem and wanted to get better insurance. Upon telling my employer of his plans, the employer came back and said, “What if we make you a full-time employee here?”
One lesson I have learned by reading about Steve Jobs and Apple is that if you just keep learning, you never know how that knowledge can apply in the future. You never when the idea for the next great thing will come to you.
Having read several books about Steve Jobs and Apple, I know that when he came back to Apple in 1997 he was focused on saving the company and trying to create four great computers. And then one day a few years later some things came together — primarily a miniature hard drive that one of his engineers discovered — and in a very short period of time the first iPod came out (and Apple as a company was saved).
After that, as the Apple team had become comfortable working with small form factors and pushing the technology envelope, they eventually created the iPhone as well.
So the lesson for me is to just keep learning, and also to keep your eyes open to what’s happening in the world around you. You never know if you’re Steve Jobs in 1997, 2001, or 2007.
Personal reminder for the day: It’s easy to be a critic, and it’s hard to do the actual work, to ship a great product. It takes no energy at all to be a critic, but it takes hundreds or thousands of hours to do great work.
I was going to share a story about someone who was a harsh critic of the Scala Cookbook when I was about 80% done with it, and how he later went on to have major problems shipping a product himself, but rather than get into all of those details, I’ll just stick with that reminder. Okay, I’ll add one point here because it is important: As a critic he had a number of good ideas, but also several crazy ideas. This got to the point of being such a distraction that I had to ask my editor to thank him for his contributions to date, but that his assistance would no longer be needed.
Getting back to how easy it is to be a critic, I used to say to one critical employee, “You get 10 points for pointing out the problem. You get 90 points for solving it.” To his credit he took this well, and became a valuable employee and co-worker.
(A final note: When I first became a manager, I thought of employees as being productive on a scale of 1 to 10, with 10 being the most productive. Initially this worked well, but after a few bad hires I realized that some people deserved negative numbers, meaning that they slowed down existing teams. While that sounds harsh, think of it this way: If you have two employees who are each giving you 10 units of work every week, you have a total of 20 units of work. But if you add someone to that team who keeps causing problems (it constantly takes time to explain things to them, they break things, they are a distraction) and is adding no good work of his own, he will slow the first two down so that their output is now less than 20. Therefore, this person’s contribution to the team speed is a negative number. (New team members will often slow down an existing team when they’re first added, but after that they should help the team’s speed, but if they don’t help improve the team speed after a while you have to take them off the team.))
“Engineers who don’t need to be managed are worth paying extra for.”
~ Adrian Cockcroft (How Netflix gets out of the way of innovation)
At one point in my consulting career I used to have to work next to a large, loud guy that one of my friends once referred to as “The Bull,” as in, “The bull in the china shop.” The Bull was an older guy who used to talk to himself loudly as he was programming, and he’d typically say, “C’mon Steve, your better than this,” and other similar words.
As I get older I find myself saying similar things to myself, albeit not out loud. I was just thinking to myself, “C’mon Al, you’re smarter than this, think harder.” I’ve come to like this approach, it’s like a way of being a constant “coach” for myself.
It’s important to remember that even when successful people say things, they’re often just opinions, not facts. Starbucks’ CEO Howard Schultz once told Jeff Bezos of Amazon, “You have no physical presence. That is going to hold you back.” The reality was that not having a physical presence at that time is what propelled Amazon forward.
(That quote comes from the book, The Everything Store: Jeff Bezos and the Age of Amazon.)
A note on how the book writing has been going lately:
“Ah, so this advanced Scala/FP feature works because of Language Feature X ...”
*work on X for several hours*
“Bah! It doesn’t work because of X, it works because of Y!”
“#%*@!”
*takes a long time to calm down*
“Well, maybe I can make X an Appendix...”
“That’s great, another Appendix. And you still need to write the main lesson that you thought worked because of X, but really works because of Y.”
*sigh*
I had a good laugh at myself this morning. A long time ago — like in high school — I wanted to be a writer. Then when I was in college I really wanted to move to Colorado, but I couldn’t get anyone to hire me. After that, I came to Boulder for the first time in 1992 and knew I wanted to live in this area.
This morning I found myself sitting in a coffee shop in Boulder, working on my new book. I actually had a little laugh in the coffee shop when this thought came to me. Sometimes things sneak up on you.
“The most depressing thing about life as a programmer, I think, is if you’re faced with a chunk of code that either someone else wrote or, worse still, you wrote yourself but no longer dare to modify.”
~ Simon Peyton Jones
I always used to tell my employees that they’d never have a bad review with me. They usually looked shocked when I said that, and then asked why. “The reason,” I'd say, “is because if you’re working with me, I’ll never let it get that far. I won’t wait for a review to tell you if I don’t like something about your work. You’ll know where you stand with me.”
Given that background, it’s no surprise that I like this quote from Broncos head coach Gary Kubiak: “Nothing drives me more crazy than to see a young player that is very talented, should be a success in this league and help his family out and himself out, and get the most and he’s not getting it because maybe he doesn’t quite understand how to work or how to be a pro. I’m not trying to be hard from that standpoint, but I just feel like that’s my job. When I’ve got those types of kids and I see that in them, I’m going to let them know.’’
“For an actor, you’re rejected eight or ten times a day. All you’ve got to sell is yourself. You’re not selling products, they’re not turning down a car, they’re turning you down. Most people can’t handle that. Most people are essentially not set up that way.”
That’s a quote from Barry Corbin, who I mostly think of as Maurice Minnifield on Northern Exposure. His quote reminds me of the sales process in consulting work. I write more about this in my online book, A Survival Guide for New Consultants.
As a quick writing tip, whenever you write something to someone else, never use the phrase, “I think,” as in, “I think the problem happened because of XYZ.” It’s obvious that you think this because you’re writing about it. Leave out the words “I think,” and your text will be more powerful.
