I was at a local user group the other night. I mentioned that I was going to do some management training to a colleague and he seemed surprised that I was getting out of the code. I'm glad he said that because it has made me more aware and reflective of my career and current situation.
In 2000 when we were using Perl, duct-tape, building jars from IDEs, Windows batch files, manual steps and bash files I decided to become the build and deployment guy introducing ant to a skeptical organization.
When I saw projects continually fail and stagnate I became the process guy. First we did what seemed right, then I read up on Scrum. I'll never go back to waterfall, not because I'm dogmatic but because I like to succeed.
When faced with mounds of green-field work in a domain I barely understood I became the requirements gathering and domain modeling guy.
Tasked with creating a scalable, flexible, testable system I became the architecture guy.
As the most senior person in a growing team and successful organization I'm slowly turning into the management guy. To most of my peers this is a stark transition. Committing to the dark side, never to return. I just don't see it that way. I'm filling the vacuum, solving problems, getting things done and kicking ass. I see it as operating from the same play-book I've had for over 10 years.
About Me
Sunday, November 15, 2009
Monday, July 13, 2009
Got a Mac
This weekend I purchased a 15" Mac Book Pro. I've used Linux almost exclusively for the past 10 years. It came down to me needing a good laptop and dreading the thought of having unsupported hardware after spending a lot of money.
I evaluated laptops from 6 companies. They all had the hardware I wanted at a great price but none of them said anywhere (that I could find) about their Linux support. You figure among them they could have thrown in an Ubuntu CD and checked to see if their web-cam works etc...
So I'm diving into the Mac experience. The first piece of software I installed was VMWare Fusion and then I got an Ubntu VM fired up. I plan on getting that set up the way I want for development and then gradually dipping my toe into writing software within Mac OS.
So far I'm pleasantly surprised, it's a great machine.
I evaluated laptops from 6 companies. They all had the hardware I wanted at a great price but none of them said anywhere (that I could find) about their Linux support. You figure among them they could have thrown in an Ubuntu CD and checked to see if their web-cam works etc...
So I'm diving into the Mac experience. The first piece of software I installed was VMWare Fusion and then I got an Ubntu VM fired up. I plan on getting that set up the way I want for development and then gradually dipping my toe into writing software within Mac OS.
So far I'm pleasantly surprised, it's a great machine.
Wednesday, July 1, 2009
Book Review: Brain Rules
If you're a programmer, you're a knowledge worker. You take raw materials like API documents and a twist of domain knowledge, run that through your brain and you produce real software that does real things.
With a job like that you should be concerned about how well your brain is functioning. Your ability to think and create is pretty much everything you bring to the table. You're not bringing connections, a strong back or winning personality if you're anything like most of the programmers I know.
So how do you maximize your brain? I've been interested in that topic lately. My most recent read is the book Brain Rules. John Medina goes through 12 high-level insights that aid in our understanding of how the brain works.
I really suggest reading the book so I'm not going to take all of his thunder. There are some big points that I think are worth sharing though.
Rule #1 - Exercise
Exercise gives you a more efficient system to feed and remove waste from your brain. Exercise increases chemicals that pretty much function as Miracle-Gro for your brain.
He recommends daily motion punctuated by 2-3 sessions of harsh activity. Adding strength training would be even better.
Rule #7 - Sleep
30% of people aren't comfortable with the normal 9-5 work day. It's in your best interest as a company to account for these differences.
Our brain is very active during sleep. A good analogy is that during sleep your brain gathers all the post-it notes you have accumulated throughout the day and has added those concepts to the relational database in your brain. Drawing correlations and categorizing data.
He describes a study where students were shown a circuitous solution to a problem. It was set up such that there was a better method of solving the problem that required some creativity to discover.
Expose subjects to the problem and let them go away for 12 hours. If those 12 hours did not include sleep 20% of the people figure out the better solution. If the 12 hours did include sleep then 60% of the people figure out the solution. As intuitive as this already should be to us, this amazed me.
You need to use sleep as a tool when solving difficult problems. Another thing I like about the book is he ends each chapter with ways you might use the information presented. The author gives an example of a company should have a meeting later in the day, expose people to the problem and don't conclude the brainstorming until the next morning when everyone has slept on it.
I won't go into any more specific rules. Some of the others are particularly helpful in the context of giving presentations. I have another talk coming up and I have refactored my talk with a lot of the authors suggestions. We'll see how it goes.
I highly recommend the book.
With a job like that you should be concerned about how well your brain is functioning. Your ability to think and create is pretty much everything you bring to the table. You're not bringing connections, a strong back or winning personality if you're anything like most of the programmers I know.
So how do you maximize your brain? I've been interested in that topic lately. My most recent read is the book Brain Rules. John Medina goes through 12 high-level insights that aid in our understanding of how the brain works.
I really suggest reading the book so I'm not going to take all of his thunder. There are some big points that I think are worth sharing though.
Rule #1 - Exercise
Exercise gives you a more efficient system to feed and remove waste from your brain. Exercise increases chemicals that pretty much function as Miracle-Gro for your brain.
He recommends daily motion punctuated by 2-3 sessions of harsh activity. Adding strength training would be even better.
Rule #7 - Sleep
30% of people aren't comfortable with the normal 9-5 work day. It's in your best interest as a company to account for these differences.
Our brain is very active during sleep. A good analogy is that during sleep your brain gathers all the post-it notes you have accumulated throughout the day and has added those concepts to the relational database in your brain. Drawing correlations and categorizing data.
He describes a study where students were shown a circuitous solution to a problem. It was set up such that there was a better method of solving the problem that required some creativity to discover.
Expose subjects to the problem and let them go away for 12 hours. If those 12 hours did not include sleep 20% of the people figure out the better solution. If the 12 hours did include sleep then 60% of the people figure out the solution. As intuitive as this already should be to us, this amazed me.
You need to use sleep as a tool when solving difficult problems. Another thing I like about the book is he ends each chapter with ways you might use the information presented. The author gives an example of a company should have a meeting later in the day, expose people to the problem and don't conclude the brainstorming until the next morning when everyone has slept on it.
I won't go into any more specific rules. Some of the others are particularly helpful in the context of giving presentations. I have another talk coming up and I have refactored my talk with a lot of the authors suggestions. We'll see how it goes.
I highly recommend the book.
Android Presentation from Denver Open Source User Group
I gave a talk on Android to the local Denver Open Source User Group. Great crowd. I got some great feedback (thanks Matthew) so I think my talk will be improved when I talk at BJUG in July and DJUG in August.
You can also get links and materials on my home page.
You can also get links and materials on my home page.
Saturday, June 20, 2009
NFJS Spring 2009
As a Denver/ Boulder area native I should be immune to any Scott Davis talk on Groovy. But Scott rocked my world again with what is possible in Groovy. I saw a bunch of great talks. The schedule was light on Grails content unfortunately.
Neil Ford gave a great talk on how to thrive as a developer and how companies should handle their developers.
Ken Sipe gave a great talk on upcoming Spring 3. Frankly most of the features are already in Spring 2.5. We just got up to Spring 2.5 at work so hopefully when Spring 3 comes out we'll get right on it. His talk almost made me regret choosing Struts2 for our web application at work. Spring MVC is doing amazing stuff. Lots of great sensible defaults and the ability to create some beautiful ReST-like URLs.
A great local talent, Matthew McCullough, gave great presentations on maven and open source debugging tools. I have considerable experience in both areas but I got a lot out of the talks.
Venkat gave a great talk on Scala. I still don't see a big reason to switch to Scala. If anything I'll be doing more and more Groovy.
Nate Schutta spoke on 'Hacking Your Brain for Fun and Profit'. That was another good book. I recently read Refactoring Your Wetware. I liked the book a lot and some of the material Nate went over was from that book. His talk was more inspired by Brain Rules. The talk inspired me to pick up that book and I'm reading it now; it's great.
I finished the weekend with a talk by Venkat. He's a good last speaker to have, he managed to keep me awake. At the end of a No Fluff weekend your brain is guaranteed to be fried. He gave a very general talk on code smell. Much of the material seemed to be from Practices of an Agile Developer. I have read that, it's a good book.
Neil Ford gave a great talk on how to thrive as a developer and how companies should handle their developers.
Ken Sipe gave a great talk on upcoming Spring 3. Frankly most of the features are already in Spring 2.5. We just got up to Spring 2.5 at work so hopefully when Spring 3 comes out we'll get right on it. His talk almost made me regret choosing Struts2 for our web application at work. Spring MVC is doing amazing stuff. Lots of great sensible defaults and the ability to create some beautiful ReST-like URLs.
A great local talent, Matthew McCullough, gave great presentations on maven and open source debugging tools. I have considerable experience in both areas but I got a lot out of the talks.
Venkat gave a great talk on Scala. I still don't see a big reason to switch to Scala. If anything I'll be doing more and more Groovy.
Nate Schutta spoke on 'Hacking Your Brain for Fun and Profit'. That was another good book. I recently read Refactoring Your Wetware. I liked the book a lot and some of the material Nate went over was from that book. His talk was more inspired by Brain Rules. The talk inspired me to pick up that book and I'm reading it now; it's great.
I finished the weekend with a talk by Venkat. He's a good last speaker to have, he managed to keep me awake. At the end of a No Fluff weekend your brain is guaranteed to be fried. He gave a very general talk on code smell. Much of the material seemed to be from Practices of an Agile Developer. I have read that, it's a good book.
Tuesday, May 5, 2009
How I Prepare a Talk
Recently a local stud tweeted a picture of 3x5 cards laid out on a kitchen counter in preparation for an upcoming talk he was going to give.
I thought it was interesting because I do nothing like that. He has a lot more experience giving presentations than I do. I tend to think if someone were looking for the right answer his approach is something to consider.
There's also a recent article on using mind maps to organize your thoughts for a presentation. I've used mind maps in the past, I'm sure that's a good approach.
I'm sure there are other great approaches to take besides these. Here's what seems to work for me.
1) get a broad understanding of the topic
2) come up with a high level outline (6 or fewer items)
3) create place holder slides for the outline
4) continue filling in information (code, bullet points, pictures, reminders) directly into the presentation software until you have something you're satisfied with
The information doesn't have to be a complete thought. I consider it like a wiki; there can be place holders for stuff I need to research more. I like it because the presentation itself becomes a series of buckets to put information into. There is no manual labor to look forward to in transcribing any other media into the presentation.
I thought it was interesting because I do nothing like that. He has a lot more experience giving presentations than I do. I tend to think if someone were looking for the right answer his approach is something to consider.
There's also a recent article on using mind maps to organize your thoughts for a presentation. I've used mind maps in the past, I'm sure that's a good approach.
I'm sure there are other great approaches to take besides these. Here's what seems to work for me.
1) get a broad understanding of the topic
2) come up with a high level outline (6 or fewer items)
3) create place holder slides for the outline
4) continue filling in information (code, bullet points, pictures, reminders) directly into the presentation software until you have something you're satisfied with
The information doesn't have to be a complete thought. I consider it like a wiki; there can be place holders for stuff I need to research more. I like it because the presentation itself becomes a series of buckets to put information into. There is no manual labor to look forward to in transcribing any other media into the presentation.
Sunday, April 19, 2009
Pragmatic Thinking and Learning: Refactor Your Wetware
I just finished reading Pragmatic Thinking and Learning: Refactor Your Wetware. The book is geared towards anyone who wants to learn and think better. It has plenty of specific details for software engineers.
The book does a lot of build up to get you to understand what it means to be an expert, what are the levels of skill and how the brain works for better and worse.
The best part of the book is the last few chapters. He puts the theory aside and gets to the low level practices along with some tools. The theory is good, it's a good build-up but I wish more of the book was made of pragmatic advice. The publishers provide forums and it looks like there are more pragmatic next steps there.
He covers mind maps. I have tried drawing some for video lectures on a technical topic I'm learning right now. I'm happy with the results and plan to use it as a way to coalesce thoughts and take notes while reading a book or watching a lecture.
Another practice he recommends is using a personal wiki. I love wikis, I use them a lot for work, I even wrote a file based wiki in Python once. I installed didiwiki on all my Ubuntu machines, it's file based so you need no database running. It's also very lightweight and has an embedded HTTP server; ideal for my Asus EEE net-book. Another benefit of being file based is that I can just version control the files (using github) and I have access to the wiki data on any computer I use and while I'm off-line.
Overall, I highly recommend the book. I absolutely tore through the book, that's a good sign.
The book does a lot of build up to get you to understand what it means to be an expert, what are the levels of skill and how the brain works for better and worse.
The best part of the book is the last few chapters. He puts the theory aside and gets to the low level practices along with some tools. The theory is good, it's a good build-up but I wish more of the book was made of pragmatic advice. The publishers provide forums and it looks like there are more pragmatic next steps there.
He covers mind maps. I have tried drawing some for video lectures on a technical topic I'm learning right now. I'm happy with the results and plan to use it as a way to coalesce thoughts and take notes while reading a book or watching a lecture.
Another practice he recommends is using a personal wiki. I love wikis, I use them a lot for work, I even wrote a file based wiki in Python once. I installed didiwiki on all my Ubuntu machines, it's file based so you need no database running. It's also very lightweight and has an embedded HTTP server; ideal for my Asus EEE net-book. Another benefit of being file based is that I can just version control the files (using github) and I have access to the wiki data on any computer I use and while I'm off-line.
Overall, I highly recommend the book. I absolutely tore through the book, that's a good sign.
Subscribe to:
Posts (Atom)