I Love JUGs

I attended the Detroit Java User's Group meeting at ePrize in Pleasant Ridge last night.

See the Google Group for details on the organization, and the Yahoo Group for the mailing list. All you need to do to join the user group is add yourself to the mailing list.

The meeting was a good opportunity to connect with my fellow software nerds, and boasted a pretty good mix of different perspectives and skills. Many of the attendees were people who coded mainly in languages other than Java, including Groovy, Scala, Grails and Flex. One of the participants was a physicist working on a 3D visualization and site navigation interface, which struck me as a particularly interesting project.

The common use of other languages raised an interesting point that we discussed briefly - is Java on the way out? The consensus (which is something I heard from the Java Posse podcast some months ago) is that Java-as-a-language may or may not be, but Java-as-a-platform seems to be gaining ground. The evidence for this is fairly solid - many non-Java languages compile to JVM-executable bytecode, allowing access to the rich set of libraries that Java provides. This includes not only Groovy, Scala and Grails mentioned above, but also JRuby, and Jython, all of which have a significant following.

I won't weigh in on which is the "best" language, since the choice of language depends on many factors, not least of which are "will it do what you want?" and "can you get / do you have developers who are productive in it?"

The presentation itself was done by Srini Penchikala, who has written about Java and other topics many times. His chosen topic was Software Architecture, Then and Now. Srini focused on the different choices that architects have when designing a system, and on the advantages of some newer technologies, such as dependency injection, aspect oriented programming and annotations. (He recently blogged on this topic as well. Here is the direct link to his slide deck.)

Most of the meeting was spent in lively discussion, rather than passive listening. It was enjoyable and informative to follow the debate about annotations and object orientation, with several different points of view presented (and argued about).

Overall this was a pleasant experience that left me with a lot of food for thought. I'll be back next month.

Turning to the JUG...

I'm heading out to the Detroit JUG (Java User Group) this evening for a talk by Srini Penchikala on software architectures. It should be interesting, given the topics he has written about on the O'Reilly site.

This is my first visit with the group, so I'll write up my impressions tomorrow.

Links 11/26/2008

Happy holidays!

Here are some resources I have found useful lately...




Ann Arbor Spark
A fairly comprehensive site with many resources for start-ups. This includes everything from an entrepreneur "boot camp" to regular meet & greet events that match start-ups with developers and other talent.

Digital Edge
This is a site devoted to small tech companies. Joe Minock (Joem32 on twitter) runs the site. Per the site, the focus is on "highly scalable web start-ups or web based businesses". It looks like they're just getting started, but I like the idea.

Twitter!
Not local, but it is turning into a pretty good resource for me to find helpful people and advice. The basic Twitter search is useless for finding people that you don't already know, but resources like Twubble and Twellow can help you find a seed group of people to follow. Check out Chris Thomson's blog entry on this for more information. After you have a dozen or so people, consider adding MrTweet - it will give you an analysis of who else you should be following.
(BTW, I'm visual_thinker on Twitter.)

"Practice" as it applies to development

CNN Money had an interesting article on "deliberate practice".   It essentially says that the top performers in any field get there by relentlessly learning to be better at what they do, rather than due to inborn talent, and that "deliberate practice" is not what most people do.

This is not a new idea, but it seems to be a good one.  Ronny Max blogged about it over two years ago, and she cited "Freakanomics" as her source, which was first published in 2005.

Geoff Colvin (the author of the CNN piece) cited eight elements that distinguish it from what most other people consider practice:

1. It is designed specifically to improve performance.
2. It is usually most effective when repeated a lot.
3. Continuous feedback is available.
4. It is mentally demanding.
5. It is difficult.
6. Practitioners set specific goals focused on process (not just outcome).
7. Practitioners "think about their thinking" while practicing.
8. Practitioners evaluate their own performance carefully.

I like the concept for a couple of reasons, not least of which is that it offers hope for improvement in any endeavor.  I disagree with one of the author's central points - that "talent is overrated".  I suspect that you must have a base level of talent for anything to reach the pinnacle of achievement in it, and that practice is how you turn "base talent" into "world class".


But how does this apply to software development?

Good question.  This isn't like practicing a physical skill, and most of the examples in the article were based on sports.  Here are three concepts that might prove useful:

Design the Goal (Items 1 & 6 above)
Think in advance what skill you want to improve with any given programming exercise.  Give yourself the opportunity to practice the skill as part of the goal (i.e., improving the skill is the primary goal), and decide ahead of time how you will measure performance toward the goal.  Some example skills include:

• Retaining and applying knowledge of the toolset (i.e., using a specific set of libraries or a design approach).
• Writing code rapidly without constantly referring to a book or API doc.
• Improving fidelity to requirements.
• Writing thorough tests quickly.

Give Yourself Constant Feedback (Items 3 & 7)
Ask yourself "how am I doing" regularly. Review the goals that you set for yourself to ensure that you're doing / learning what you wanted to do / learn. Also consider your mental state - are you remaining focused on task?  Are you letting yourself  get distracted? Do you really want to attain this goal?

Evaluate Your Performance (Item 8)
As soon as you're done with the process part of the exercise, consider carefully what you should do differently next time. Take some notes!  You want to do it right next time, rather than avoiding the situation entirely.

Productivity Tools

I have spent a lot of time trying to find the "perfect" system for personal productivity.  Here are a few things that I have learned...

Having a system to capture information is even more useful than I thought it would be.  I use something similar to the system described here, which is based on Microsoft OneNote.  In essence, every day (which means nearly every weekday, and some weekends) I create a new page with the date as the title, and then "dump" information into it.  I add checkboxes for to-do items, etc.  I also keep my "daily log" pages in the folder that synchronizes with OneNote on my phone, so today & the past few days of notes (plus a couple of persistent pages) are always on there.

This has worked out great as a to-do list, since OneNote also lets you see all "flagged" items, including those marked with different types of checkboxes.

This leaves out one very important thing, though - keeping information up-to-date in my own brain.  This is something that all of the GTD Gurus specifically tell you not to do.  The idea being that information and to-do items "take up space" in your mind, and prevent you from thinking more creatively.  There is a point to be made there, but I think that Allen and others take the idea too far.

My take (which really isn't wildly different from Allen's "weekly review" process) if that you should review your own notes regularly.  Things that still seem important the next day (or the next week) probably are.  I also don't think that this process should be overly formal.  Just spot-check some things from last month, last week, and yesterday.  One thing I hate is to constanly review "to-do" lists that I can't yet take action on.  Reviewing thoughts, ideas, and opinions of other people and their ideas is another matter, so I try to keep my "to-do" items down to only a handful, and the other information more verbose.

What is a Systems Architect?

I have been re-growing some software development related skills, with an eye toward going from "Java Team Lead" to "Java Architect". What does "architect" mean, though?

Sun offers a certification for a Java platform "Enterprise Architect". Based on the objectives for the exam, they define it based on experience with system design that takes into account flexibility, security and other factors.

This topic has been discussed in a number of other places, including this Javaworld article, which makes the points that most positions billed as "Architect" slots are really "Senior Developer" positions. The author's take is that an architect has breadth rather than depth of knowledge.

This I agree with. To me, a true "architect" is someone who:

• Knows what technologies are available to solve a given design problem.
• Has a handle on "systems thinking" - a way of approaching problems and designing solutions that looks at the whole rather than decomposing the problem and then attacking the smaller issues that come from this decomposition.
• Also has a software development skillset.
  

The first bullet point is something that you can train yourself to do. It entails keeping abreast of what technologies are available, what they're good for, and a realistic assessment of the maturity of each of them.

The "also" in the last bullet point reflects my perspective that an architect is a "developer and..." rather than someone who is really good at software development. I think that you can be a great architect even if you are just a "good" software developer if you have a handle on other skills. For instance, a strong communicator can help move people toward the best technologies by explaining the benefits. Someone who is a really quick study (and hence can understand new technologies easily) will have more options to choose from when designing a solution.

The "systems thinking" point above is the most difficult one to train. If the only problem-solving approach you have is to deconstruct, you probably won't be a great architect (don't lose hope, though - kick-ass software developers are just as valuable, and just as hard to find). Systems thinking is also one of the most difficult things to define for people who don't do it regularly. It is more a way of experiencing the world than it is a discipline. Though there are plenty of descriptions and examples to be found, very few purport to show you how to do it.

So what does this mean for the aspiring architect? Stay in touch with available technologies! Subscribe to blogs and software-related news feeds, join user groups, go to conferences, and read, read, read. If you aren't reading at least one (and preferably two or three) technology book per month, you're falling behind.

Expertise and Competition

Companies are better served by having a few really good people on a project vs. a large number of ineffective ones. This begs a couple of questions:

• Do you potential clients believe that it is better to pay for quality than quantity?
• Who is your competition, and are you better than they are?
  

The Competition

Let's start with the second question: when you are an independent consultant, who is your competition? As a rule, it is not other independent consultants. According to this bureau of labor statistics report, only about 4% of programmers are self-employed. According to this one, only about 6% of systems analysts are self-employed while, this report indicates that only about 2% of "Computer Software Engineers" are self-employed.

There is a lot of overlap between each of these groups, but the bulk of the "tech lead" work will fall into the systems analyst and software engineer groups. That is what I'm mainly seeking, and I assume that you are as well if you're reading this.

So who is the competition? My own experience tells me that when the time comes to staff a project, 90% of the candidates I have seen fit two or more of the following:

• Little or no "initiative" - only do work when given very specific tasks.
• Little or no talent for creating software.
• Non-native speakers of US English with poor communication skills (mainly from India since that's the bulk of the talent pool right now, but many US-born programmers have this problem even without a language barrier).
  
• Limited understanding business in general and the purpose of business software in particular.
• Very little experience with 'real' programming work (as opposed to school projects).

To sum up: if you communicate well and are motivated, you're head-and-shoulders above your competition. (For more on this topic, here is a blog entry with some pretty good quotes on what it takes to be a "good" programmer.)


Your Potential Customers

This is where the rubber really meets the road. I think that most software developers understand on some level what it means to be good or bad in this space. I think that most business people do not know this, but believe that "programmers" are mainly interchangeable.

This state of affairs is changing slowly, and there are a number of voices out there (like this one) that seem to get it.

To find the work you want to do and make a good living at it, you really need to do two things:

1. Sell your clients on the idea that they get a lot more benefit from a few good people (like you!) than from a large group of mediocre ones.
2. Build your expertise to the point where you're obviously one of the best.
   

Both of these will be the subjects of future posts. I would really like to hear your opinions in the meantime!

The Beginning

Detroit. A city filled with good restaurants, violent crime, and felonious politicians. The city I grew up in and that I still live near.

This is not a blog about Detroit.

It's a blog about something far, far more important. Me.

More specifically, it's about my journey from employee to independent. It's about returning to my roots as an über-nerd software developer. It's also about Java's place in the world, and the independent consulting market in Detroit and Ann Arbor. I don't think I'll run out of topics any time soon.

I resigned my job as Program Manager in a struggling software company last week. There were a lot of reasons behind that, but the most important one was that I couldn't stand my job.

I didn't hate the people. I didn't hate my boss. I hated the actual work I was doing from day to day.

I'm getting ahead of myself, though. Before I tell you where I'm going to, let me tell you a little bit about where I'm coming from.


The Salad Days
Very early in my career, I worked as a contract software developer. I was directly employed by a couple of different shops until I met a fellow developer at a software company in Ann Arbor who also yearned to go into business for himself. Starting in 1994 we set up shop under the inspired name of "Damon, Przekop & Associates, LLC".

Those were heady days. Anyone with the ability to register a domain name could put up a website and bill themselves as a solution provider. A few really sharp people did so, as did a large number of clueless ones. It was a time when work just fell into our laps, and customers were grateful when we managed to deliver a working system, regardless of the quality.

We took whatever came our way. Need a client-server database app? "Sure, we can do that. Erik knows Visual Basic and Dave can handle the SQL work." Need some realtime work done? 'We know C++, and we can learn realtime in a hurry. " Want to piss away a couple of million on an voice-recognition-based CRM that will never see the light of day? "Java is the platform you want! (I guess we had better learn how to code in it.)"

Companies got wise after the bubble burst in 2001. They wanted their contractors to have some idea about how to ensure software quality. They wanted us to write systems that actually did what they needed. The approach of ignoring the customer's needs in favor of working with the flavor-of-the-month technology was no longer acceptable.

Our skillsets simply weren't up to that challenge. We both had a really good grasp of the basics of writing code, and we could do it in 10 different programming languages. The problem was that neither of us had true expertise on a specific development or delivery platform. We hadn't specialized, and we didn't know jack about QA, requirements or agile development.

A couple of companies came to the rescue. Dave was hired by a software company in Monroe, and I moved to a data company in Southfield. Both of us were tired of the grind and were ecstatic that someone actually recruited us away from what we perceived as a failed way of doing business.

I became an employee again, and learned quite a lot in two years as a technical lead. I specialized in Java development, with a focus on the process of software development. I learned how to get a team to deliver on time, how to gather requirements, and (after having my head handed to me a couple of times) how to see testing as my friend instead of as a pointless waste of time.

Then, something very bad happened.


Drawn to the Dark Side
That's right, I did such a good job as a tech lead/architect that my bosses foolishly thought I would make a great manager. It turned out that they were at least partially right - I did a pretty good job of managing software & support people, and I turned into a process-Nazi in a big hurry, which was just what the organization needed. I was rewarded financially and became the go-to guy for evaluating the capabilities of smaller companies we might want to buy. It was challenging, and usually fun.

Things went downhill after a couple of years though. My success was rewarded by giving me a job doing pure infrastructure management because that's where they needed the most help. For those who do that job well, hats off to you. I was mediocre at it at best, but I stuck it out for most of a year.

When the time came for cutbacks, my name was one of those that came up. I found myself on the street (with a severance package that took some of the sting away), wondering what to do next. On pure inertia, I put my name out there as an "IT Manager", which brings me back to my current job.

Jokes aside, I learned quite a bit as a manager that I wouldn't have otherwise understood. You simply can't get this stuff from books. How seemingly non-technical" people can add a lot more value than some of the rocket scientists. Why it's important to pay attention to office politics if you want to get anything done. How to plan for success, but still guard against failure. How to build and balance a team.

I also learned how much I hated doing it.

I really have nothing against management as a profession. Quite the opposite. I will now appreciate a good manager much more than I did before, and the management skills that I gained should serve me well in a technical job.

I did find that most management jobs (particularly infrastructure) require a very thick skin. Mine may not be quite thick enough, but I think the real problem for me is that it isn't what I "should" be doing. I just don't have any passion for it.


The Lightbulb Goes Off
I've been kicking this idea around for a year. While doing infrastructure work, while hunting for another job, and a lot while handling my latest job, I asked myself, "Why not go back to consulting?"

What held me back was the perception that I had failed at it before. I just didn't have enough customers, or enough expertise... or something. So I took a long look at what I did back in the 90's, and what it would take to make it work now. I came up with some answers.

That brings me back to what this blog is really all about: How to build and sustain a consulting practice based on my own expertise. How to build that expertise, find the right projects and clients, and sustain a small business for the long haul. My initial thoughts on what I did wrong then, and what I will do right going forward, will be the subject of another post.

If anyone who reads this is in the same boat, I would really like to hear your thoughts and opinions. If anyone has built a one-man (or one-woman) business out of writing code and/or architecting software systems, I'd really like to hear your thoughts.

I don't expect much feedback right away (though I'm prepared to be pleasantly surprised - I didn't come across anything else that really focused on this topic). I will add some useful links and observations from my own experience in future posts. I will also post snippets from projects I have worked on over the years, the steps I took to get things on track, and mistakes made that I learned from.

I look forward to hearing from you.