Archive for June, 2009
I haven’t had a chance to upload all the photos to my Flickr account yet, so here are my top (Facebook-enforced) 200 favorites. If you are looking for an awesome wedding photographer, I highly recommend the guy who shot our wedding – Phillip Lloyd.
We should be getting the video in a few weeks, so I will post that when I have it. In the meantime, enjoy the pics!
A while back, I blogged about how I hate autocomplete=”off”. While I’m loving the new Safari 4, unfortunately the upgrade process from Safari 3 overwrote my patched version of WebCore, which was previously set to ignore this idiotic HTML attribute.
Luckily, the Autocomplete Always On! script still works on Safari 4, so have at it.
Bruce Eckel just posted a blog post about how to get in to a career in computing. He starts by posing the question “should I learn C++ or Java?” and throughout the post indicates how thoroughly irrelevant that question is to a successful computing career.
It’s a great article overall, but based upon my experience, I think this statement Bruce makes in his post rings truest.
“When the Internet was first booming, all you had to do was spend some time learning HTML and you could get a job and earn some pretty good money. When things turned down, however, it rapidly becomes clear that there is a hierarchy of desirable skills, and the HTML programmers (like the laborers and sheet rockers) go first, while the highly-skilled code smiths and carpenters are retained.
What I’m trying to say here is that you don’t want to go into this business unless you are ready to commit to lifelong learning. Sometimes it seems like programming is a well-paying, reliable job — but the only way you can make sure of this is if you are always making yourself more valuable.”
He also lists the output of a seminar where participants highlighted qualities in ideal job candidates for software developers.
“There is no right answer … and always a better way. Show and discuss your code, without emotional attachment. You are not your code.”
I’ve worked with a lot of different programmers in my career, and I’ve found that the best ones had these two qualities Bruce describes in common: a commitment to lifelong learning and emotional separation from their code.
The guys I worked with who had not committed themselves to lifelong learning typically fell in to the category of people who learned a language because programming jobs in that language were hot at the time they got in. If these are your motivations for becoming a programmer, I have very simple advice for you: choose another career.
People who learn one hot language just to get a job mostly find themselves ten or more years later as one-trick ponies on outdated software platforms. Since they have no real interest in learning anything else, there’s a huge degree of insecurity associated with learning anything new, which has a direct impact on how they react to ideas to improve their trade. This is easy to spot; instead of welcoming alternative approaches for their merits and engaging in debate, these guys are the ones who will dig their heels in against change and do everything they can to maintain the status quo, regardless of whether or not the solutions are meeting the needs of the end users/software requirements. This is a one-way ticket to a dead-end career.
I like to consider myself in the other camp, which is programmers who embrace the lifelong learning process. However, I also try to be realistic about my ability to stay in this camp for the long term; there are trade-offs to both career choices.
To be clear, I love writing software more than anything else about my work, but I also enjoy the occasional breaks from the “grind” when my management responsibilities take center stage. In short, writing high-quality software requires a ton of focus and discipline, and unless you take constant pleasure in this you will find yourself hating your job. When you hear about engineers getting burned out, it’s usually due to being forced to stay in a focused state for an extended period of time. Both (a) the need to constantly change your methods and approaches, and (b) to learn entirely new languages to produce the best solutions and leave your old skills behind require a huge commitment both personally and professionally. Case in point, after ten years in the field, I’ll be learning Groovy from one of the guys on my team next week since we determined that the Grails platform will be the best thing to support our web service endpoints.
While I don’t know when (if ever) I will get burned out, I could definitely see myself leaving coding behind one day in the future. I’d still be involved with software, but I would replace coding with more managerial responsibilities, perhaps focusing more on software team management or product management needs. If that day ever comes, I think I’ll always be a tinkerer; after all, if you love programming, that love stays with you forever. I learned last week that my periodontist used to be a UNIX programmer before he got burned out, and he still messes around with coding on the weekends.
I had a chance to get out of coding earlier in my career, when I took on a senior management position. It’s a lot easier to manage software than to produce it as your personal output, and in a different company I probably would have stayed with the management role. However, the company I worked for was not a technology company, and this meant that I spent more time managing the concerns of the business than the development of their software. Since my passion is ultimately for software, I just didn’t care about my career continuing in that direction. I’ve since made the switch to work in the tech sector, and can now honestly say that if I was given the choice between a career developing software in the non-tech sector and switching careers, I would switch careers. So, even if I end up in a primarily managerial role in the future, it will be for a tech company.
In closing, my advice for budding software engineers is this.
1) Know that you love software before you commit to it. You’ll know when you take your first pseudocode class: a clear division forms between the people who get it and the people who don’t. If you’re in the “don’t” section, choose another career.
2) If you don’t like teaching yourself new things, the skills you learn today will be irrelevant in less than a decade. Accept the commitment to learn throughout your career as a coder, or accept your eventual fate as a has-been.
3) College degrees matter less than hands-on knowledge and time spent at the keyboard. I outpaced my entire class in college because I bought my own programming books that deviated from the coursework, and as a result I learned things they were not teaching in school.
4) College degrees still matter. There was a lot of stuff I missed in my two-year AS degree at a community college that I ended up learning either through experience, or by rubbing shoulders with colleagues with four-year CS degrees. If you can’t make it through four years of school, make sure you pick up a book on programming algorithms and learn the classics before you hit the workforce.
5) Early on, decide if you want to focus on application development or software engineering. Application development deals with making user interfaces, interfacing different systems together, solving business process problems, and exposing applications to the outside world (i.e. web services and other remoting techniques). Software engineering deals with creation of utilities and processes that support information processing, tends to be more math intensive, requires a lower-level understanding of the trade, and rarely deals with the systems that expose the software to an end user. There are core differences in these two disciplines and 100 shades in between, so figure out what you like.
6) Once you know what you want to do, seek a job that puts you in an apprenticeship role with an actual person as your mentor. Companies that support co-op programs and allow you to learn from a mentor while contributing to a team produce the best engineers. If you find that you are plugged in to a position like a cog in a big machine, and have “ivory tower” designers/architects handing out instructions without teaching you the “why”, find another job.
7) If you decide to program software for a company whose core business is not technology, know that in most of these companies the quality of the software is not important, and your role in the organization is considered expendable. In these companies, IT is usually the first department to get cut when things go south, and you will sometimes be forced to make crippling compromises in the quality of your applications to meet short-term business needs. That being said, you will often get the opportunity to directly impact the work of people who you see regularly and share in the success of the businesses your software supports, so there are tangible rewards to this avenue.
8 ) If you decide to program software for a company that sells their technology, they tend to treat their engineers better than corporate IT shops, and cut their engineering staff last when things get bad. On the flip side, in tech companies there is a lot more pressure to produce and meet deadlines; if the software doesn’t get produced, there is nothing to sell, and the company goes under. You will also be less connected to the people who use your software since they often don’t work for the same company.
These thoughts are obviously just my own experiences, but hopefully you will find them useful if you are considering getting in to the field. Whatever you decide, if you love programming in school or as a hobby I can assure you that you will also love it as a job. I wake up every morning and can’t wait to get to work to fire up my IDE and knock out some more code.
Most Popular Yelling
- Scrolling Large Data Sets in Flex Charts (41)
- Configuring Tomcat SSL Client/Server Authentication (28)
- Fixing "Bluetooth audio failed" Error Message on Mac OS X with Sony DR-BT50 Headphones (16)
- How To Become A Software Engineer/Programmer (15)
- Using Axis's wsdl2java in a Maven Build (13)
- Speak and Spell Samples (13)
- An Objective-C Tutorial for Enterprise Java Programmers (12)
- On A Personal Note (10)
- Abandoning ColdFusion? (9)
- Adobe Says: "Thousands of Developers are using CF 8" (9)
Stuff I Like
- October 2011
- August 2011
- April 2011
- March 2011
- January 2011
- December 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- January 2007
- December 2006
- August 2006
- July 2006
- June 2006
- April 2006
- February 2006
- December 2005
- November 2005
- October 2005
- August 2005
- July 2005
- June 2005