Category Archives: Employment

03.18.13
by

Life at Google

NY Times has an article about working at Google: Looking for a Lesson in Google’s Perks.

Among them:

  • private reading areas
  • comfy chairs (take your laptop elsewhere for a change of environment)
  • custom workspaces (let employees choose their equipment)
  • fitness classes
  • in-house courses (on a range of subjects)
  • free food/snacks

All of this is designed to make the workplace one that is both fun and productive. Of course, in a company with the size and profits of Google, such things seem to work very well. From the article:

Ben Waber, who has a Ph.D. from M.I.T. and is the author of “People Analytics,” is, at 29, the median age of Google employees. His company, Sociometric Solutions in Boston, uses data to assess workplace interactions. “Google has really been out front in this field,” he said. “They’ve looked at the data to see how people are collaborating. Physical space is the biggest lever to encourage collaboration. And the data are clear that the biggest driver of performance in complex industries like software is serendipitous interaction. For this to happen, you also need to shape a community. That means if you’re stressed, there’s someone to help, to take up the slack. If you’re surrounded by friends, you’re happier, you’re more loyal, you’re more productive. Google looks at this holistically. It’s the antithesis of the old factory model, where people were just cogs in a machine.”

The overall tone (and the article is written somewhat as a response to Yahoo’s recent clampdown on working from home), it seems that the goal at Google is to inspire people to enjoy work and collaborate more effectively. Continue reading →

07.12.12
by

Staying Current

During nearly ever job interview I’ve ever had, on the phone or face-to-face, I’ve been asked some form of the question, “How do you keep your experience current?”

Sometimes (emphasis on sometimes) this is asked by someone who seems impressed that I have such knowledge on a fair amount of “new stuff.” More often this is a genuine question (and a very good one) asked of an interviewee in an effort to gauge the type of software engineer that this candidate may be. Does this candidate have a desire to keep current with emerging trends? In many ways this is a unique necessity in the world of software engineering as a career.

Software engineering is a discipline that requires a real love of the work. Its not something that anyone hoping to find easy employment stability along with a solid paycheck should pursue (warning to those considering Computer Science).

So the question remains: How do you “keep current?”

No matter how much I love software, the fact remains that I have a life outside of work: family, friends, hobbies… Its not easy, but its necessary. One guy suggests learning a language every year. I like to pick up books that look interesting, read Stack Overflow and listen to podcasts. Woe to the “software engineer” who wishes to dismiss all emerging technologies as gimmicks or buzzwords… Such engineers will quickly find themselves (if lucky) performing maintenance work on antiquated legacy code. As long as software is something of a hobby, something that is personally rewarding, all of the above should be easy enough.

While all of the above is good, and its even better to have a pet project, I have found that nothing compares to working around extremely intelligent people for a company that is serious about software.

02.05.12
by

Interview Tests – JavaWorld

I recently interviewed with a number of companies for a number of positions. Some of these interviews were phone screens and some face-to-face. A few times I was asked some very specific “test” type questions which, as a good Java programmer, I should know. Sadly, more than a few times, I fumbled for an answer… Its frustrating to be asked a question that you know the answer to but fail response correctly.  Its an even worse feeling to not know the answer at all (regardless of the fact that you have done it 1,000 times), but know you have the capability.

In one interview I was asked to describe the difference between an abstract class and a template in Java. On another occasion I was asked to describe the difference between and inner and outer join. I know the answer to each question, but I messed up during the interview, and I came across looking as if I didn’t know what I was talking about.

During another interview I was asked specifics about how and why I made decisions about system architecture, what technologies I chose and why I chose certain directions. I was asked what open source tools I used. This, to me, seemed like a much more appropriate series of questions. It gave the interviewer a chance to understand my thought process, and see that I have the ability to put concepts to practice. It didn’t put my on the spot, asking a pass or fail question (of which I may know the answer to, but flub).

I’m not saying good programmers shouldn’t be able to answer questions like those I listed above. In fact they should be able to. I’m suggesting, having sat on both sides of the interview table, that the latter approach provides a much better analysis of the candidate.

Kandice Rupert, Kandi Rupert, Kandi Kasper, Kandice Kasper

Tough tests flunk good programmer job candidates – JavaWorld.

01.29.12
by

Here’s how to solve America’s developer shortage – JavaWorld

I want to write more about this article when I get a chance. Having recently been back on the job market I have some opinions about this. I don’t think there is a shortage of IT workers. Rather, I think there is a shortage of GOOD ones.

Here’s how to solve America’s developer shortage – JavaWorld.

11.06.11
by

What Every *Good* Developer Should Know

I came across this guy’s blog post titled “10 Things Every Good Web Developer Should Know.” The post is geared toward web developers, but it did get me thinking a bit about the more general questions. I’ve noticed shortcomings among developers (myself included) for a many years. What are some of the things that all GOOD developers SHOULD be expected to know? This list is hardly comprehensive, but I can think of a few things right away:

1. Linux/Unix

If you can’t do basic editing in vi you may find yourself in for a world of hurt at some point. I’ve known many programmers who attempt to write software in the safety of their IDE running on Windows only to find severe problems when it comes time to deploy on the server (and the server is typically some flavor of Linux). I recall a fellow software engineering student in my college days saying of his code, “It all works, it just won’t compile!” It sounds silly, right? Assuming software that is written, build and deployed in Windows will built and deploy just fine in another OS is equally as silly (yes, this goes for Java as well).

2. How to debug

Duh, right? Not so. I have helped many, many engineers with basic debugging. I don’t know if it is that I am particularly good at debugging (I’d like to think so), or that (some) others are particularly poor at it, but for most of my career I’ve heard, “Matt, this isn’t working, can you help?”

Generally this question is asked by an engineer who has spend a fair amount of time staring at the screen hoping to gain some diving inspiration and fix a bug. It never works this way. You have to be willing to dig into the code and actually find where the error is. Look through that stack trace! Run the debugger! When all else fails, start sticking print lines all over your code! Staring at the screen will rarely reveal a complex bug. A compile error, sure, but a bug, no.

3. Basic knowledge of C/C++ and or Assembly

In the day of virtual machines, powerful IDEs, scripted languages, OOAD and encapsulation on top of encapsulation on top of encapsulation, it can be too easy to write code and never understand exactly how much stuff has to happen for that code to work its magic. I have not written anything in assembly since college, and I have not written C code for 10 years, but I rely on my knowledge of the low-level “stuff” every time I write code. It helps to understand fundamentals of computer science, optimization, memory handling and what exactly makes all the magic of a 4GL come together. Many people get by without knowledge of assembly language, sure, but these people will not be “superstar” engineers… They’ll be programmers.

4. Version Control

There’s no excuse for not using version control. I would say it borders on negligent not to.

5. HTML, CSS, Javascript
This one may seem like another no-brainer, but I have run into many developers over the course of my career who simply do not have anything more than the most basic understanding of HTML.

6. System Administration

Just the other day sendmail quit working for me. I use sendmail to alert the team about project activity in Redmine, Subversion and Jenkins CI. I run project management software that is served using Ruby and Rails, Apache and Tomcat. I have written perl scripts for handling batch jobs and specialized email alerts. I have written bash scripts that tie in to various subversion triggers. I have installed Ant, Maven, Git, Subversion, Tomcat, Apache, GTK, GCC… You name it… All with NO help from a Linux administrator. Like it or not, these activities become the responsibility of the lead software engineer. If you embrace it and enjoy it, life will be easy. If you are lost, and waiting for the help of a system administrator, you may be in for a very long wait!

7. Database Design

EVERY good programmer MUST understand things likes normalization, joins, foreign keys, natural keys, sequences, race conditions, locking, and on and on. We cannot rely on a database designer. Even the largest companies I have worked for have, the ones with database administrators, have little if anything to say about database design. Database design is the responsibility of the software engineer. A poor design can cripple what may otherwise be good software.

8. Quality Assurance

Our goal as engineers it to deliver a high quality product with no defects. We all know that there will be defects, but this fact does not change the goal.

9. Communication, Documentation, Technical Writing

Even if your company does have the means to hire a dedicated technical writer, that employee will have no idea what your code is doing. Strong documentation is on the engineer (us). I never had to take a technical writing class in college. Fortunately, writing is something I enjoy. For the engineer who hopes to never have to write a document, he or she is likely to be very annoyed in this career.

02.23.11
by

The Software Glass Ceiling: Software Management

The Peter Principle says, basically, that people are promoted until reaching a level of incompetence. I think the reverse of this can be true as well: An employee may not be promoted because he or she performs very well in a given role.

This is just me talking, but I think there are a few problems with the way we view employment hierarchies in the software engineering world:

  1. Managers never knew software development
  2. Managers who used to know software development have been away from it for so long that they no longer know it
  3. Developers don’t know management
  4. There is no clear promotional path for the motivated software engineer

I’ve known a number of software developers who have either turned down promotion or given up a management role because they preferred software development. I suspect then, that the people left to do software management are either people who didn’t like software development or were not very good at it. This isn’t to say that they aren’t great managers (they may be), but it does lead to the possibility that the people in charge of software decisions may not be the best equipped to make those decisions.

Managers Never Knew Software Development

These days many large companies like to assign a PMP to a software project. This is an individual whose job is only to “manage a project.” The individual contributors of the team (software developers, testers, writers, etc.) don’t actually report to this person. The project manager’s role is specifically to work on timelines, track progress and ask the people who are working diligently to report their status (presumably for input into the timelies). If the company doesn’t have a dedicated project manager, this set of tasks falls onto the shoulders of some other manager.

What ultimately happens is that a lead developer will be tapped for all this information anyway, since the project manager, who doesn’t know software development and isn’t writing software, isn’t equipped to provide a meaningful level of detail in this regard. Interrupting a software engineer to ask his “status.” achieves nothing that a good project plan and appropriately used ticketing and version control system cannot.

That said, a good project manager is an individual who knows and understands software development and can provide project status details to upper management without constantly interrupting a team. I’ll take it a step further: I don’t think there is ever a need to have a project manager on a team who isn’t in some way directly contributing to team goals. This doesn’t mean that the project manager must also be a software engineer, but the project manager should be a product contributor. Creating timelines, scheduling meetings and asking people, “When will you be done with that?” is not a full time job!

Yes, we may need a “project manager,” but only if the amount of work is so significant that project management activities are warranted. A better model, in my mind, is to have the group manager, that person who is responsible for the project, have a working team lead for each subgroup. In many cases I think a single team lead of all activities (software, QA, documentation) can suffice.

Managers Who USED TO Know Software Development

Here’s something that annoys me to no end: For a software engineer to take his or her career to the next level, moving into management, seems to require giving up on ever actually engineering software again (at least in the workplace). Ironically, the very people who are required to be hands-off are also expected to make major decisions about software, while their software expertise dwindles. Software engineering is a unique discipline in this regard. As a friend of mine recently put it, it is one of the few careers in which those of us involved with it essentially learn all new stuff every 5 year years.

I find this strange because, in my experience, there very best software leader is not the MBA or the person who has never been a software engineer, rather, it is someone who is STILL a software engineer; Its someone who knows what is going on in the world of Ruby, Rails, Grails, Hibernate, Spring, JQuery, Clojure, , Git, Maven, etc. because he/she is someone who uses such things regularly. The manager whose most recent software engineering experience is a string as a Cobol developer on an AS400 years ago isn’t very well equipped to make assumptions about the effort involded with a web application, for example. 20 years from now I don’t want to be telling some junior developer how easy a project should be because “I wrote the same thing in Java in 2 days back in 2010.”

No Clear Career Path

What I’m getting at is this: A software engineer NOT have to give up writing software in order to move into management (even beyond the lead engineer role). On the contrary–I think it would be better if software management, from director on down, included actual software engineering.

02.19.11
by

The Software Glass Ceiling: Career Path?

This is a somewhat old article (2006), but it eludes to something that I have found a bit bothersome about attitudes regarding software engineering career paths.

I recently interviewed for a Business Analyst position with the CIO of a large multi-national software development firm. This man was in charge of the company’s worldwide IT operations, including offshore development projects, for which he was searching for qualified Business Analysts. The interview quickly became a casual conversation about current trends within the IT service sector, how the company was planning to take advantage of those trends, and, most importantly, how I could fit into those plans. It was during his evaluation of my skills that I asked how I fit and whether it was technical or business skills that were most valuable to his projects. The CIO summed up his advice about my career path with one small sentence: “Stay on the business side.”

The author goes on to state:

My job searches have suggested that business and systems analysts with a good programming background and a high-level of “business savvy” are becoming the next hot ticket. More and more organizations are finally hiring business analysts to explore, record, and recommend systems that fit the business—as opposed to the other way around.

While I agree with what the author is trying to say here, I think he missed the point. And the CIO quoted above is severely mistaken… Sure, you can train anyone to “be technical” and write a program, but you cannot train those people to do it well. There is a big   huge critical difference between a software developer and a good software developer. I first observed this in college, when some of my classmates loved working on programming assignments and performed very well on such things, while others fumbled through the simplest assignments, unable to get their code to compile, much less work.

Why were such people majoring in computer science? I’m not sure, but its probably because they thought they liked computers and would therefor like programming, or maybe because they heard it would make for a good career.

I don’t mean to pat myself on the back, but I (like many others in my field) didn’t realize that software engineering may be a good career until I was well into my Computer Science major. I started writing simple programs in the 6th grade, going to the library and checking out every single computer and computer programming book I could find. Later, after I had read all of the books that the small local public library had on the subject, I discovered Nibble magazine (also available at the library). Every good/great programmer I know is someone who landed in the career because it was something that he was drawn to naturally, and most of these people began at a young age. These are the people who write software because they like it, and this is why they are good at it.

Anyway, at one point, after being frustrated that my library didn’t have any more computer programming books to read, I found a strangely titled book that had been misplaced next to a book about Applesoft BASIC: The Peter Principle.  I checked it out, if only because I thought the title was funny, and I took it home and read it–all of it! I was probably the only 7th grader in the world to ever read the book, which by that time was already very dated. The closest I had ever come to the corporate world by that point in my life was delivering newspapers. I was a fairly competent paperboy, and even if I wasn’t, failing as a paperboy doesn’t lend itself to a very clear path of promotion. That said, the wisdom of The Peter Principle was lost on me.

Little did I know that years later this strange book would be remembered much more vividly than the Applesoft BASIC book that I had checked out dozes of times.

The CIO, probably much older, wiser and richer than me, missed something major: Anyone can write code, but do you want just anyone making important technical decisions that can make or break your project, department or company? I didn’t think so either. Not just anyone can write good code. I’ve seen the results of software written by cheap labor… Indeed, I’ve rewritten code written by cheap labor!

I think there is a very obvious career path for software developers, and it doesn’t necessarily involve moving into a role that no longer includes hands-on software development. I disagree that upper management doesn’t realize this. I think in many organizations they do. I intend to write more on this subject…

[Career Paths for Programmers by John Bennett, Jr. - developer., Developer Dot Star]

11.29.10
by

The Myth of the Genius Programmer

I’ve always gotten a chuckle from job posts or emails that state that an employer is search for a “Ninja” or “Genius” programmer. I always assume this to mean that the employer is looking for a single person who can handle an incredible workload alone. I like this video because the presenters (Brian Fitzpatrick and Ben Collins-Sussman) do a great job of explaining the problems that come with viewing a programmer in such a way.