by ·0 Comments

I’m a pretty organized person. I try to strike a balance between having things planned out and being flexible. There’s a cost to overplanning and putting more effort into organizing than strictly necessary, but I thin most of the time I’m glad I put in the effort.

One reason I do this is that I have learned the hard way over the years, that you can waste some effort capturing too much information and never using it later, but you often can’t go back in time and capture that information if you later find you need it handy. It’s like taking lots of photographs at a special event because it will never happen again, so anything not captured can’t be captured later. The same is true in monitoring and logging your computer systems.

I have found MANY occasions where having recorded details about current and past transactions from my job search has paid off, and I have made that as quick and painless as possible to reduce the burden.

Continue reading
Share

by ·0 Comments

I’ve been a Software Engineering Manager or Team Lead for a long time, and Agile coaching has been part of all of those jobs. I’m on the Board of Agile New England, and have been for about 10 years. I’ve been supporting the Agile community for about 13 years. Having helped multiple companies with their agility, I also have a feel for what works in specific situations, and a pragmatic approach to what and how implement it.

I enjoy management,  but after speaking to some Agile Coaches I know well, I am looking to for Technical Agile Coaching positions instead. They both focus on something I am passionate about, which is focusing on the effectiveness and happiness of the entire team. They’re just going at it from different angles.Continue reading

Share

by ·1 Comment

I think a lot about process, process improvement, productivity, and efficiency vs effectiveness (believe it or not the difference is not universally understood).  Lately I’ve been thinking a lot about team composition and how it affects the productivity of the team.  In part I’ve been thinking about it because of the teams I’ve had in the past; in part because I’m currently hiring and having to make trade-offs like salary level vs skill level and overlapping skill sets, but also because I’ve been playing the game Overwatch a lot, where team composition essential.

Continue reading

Share

by ·0 Comments

When I phone screen a Java candidate, I ask just two technical questions to assess their competency and give me a feel for where they are on the scale of “Heads-down coder” to “Java Software Engineer”.  In general, I try not to discount any candidate on just one factor, because we all have different weaknesses and strengths.  That’s why I consider these assessment questions instead of must-haves.

This is especially true of SQL questions in interviews.  I am way more interested in their thought process and how they come up with an SQL query than I am the query they respond with.  I’m not testing whether they have SQL syntax memories; I’m testing whether they understand how relational data can be joined and aggregated and filtered to produce the desired results.
Continue reading

Share

by ·0 Comments

Performance evaluations and performance management are areas I disagree with many Agile coaches’ opinions on.  “Popular opinion” is that you don’t evaluate individual team members at all.  You only evaluate the team as a whole.  They maintain that team members are self-motivated and will do their best to support their team.  They also feel that evaluating individuals on the team could lead to stratification, and all team members should be treated equal and be at the same level.  Team Leads have no place in Agile.  When a team member is not performing, or is hindering the team, the team should have the power to remove that person.

Personally, I have never seen an Agile group where everyone was at the same skill level, let alone contributing to the group to the same extent.  In fact, in most teams I’ve seen, different team members have a different level of commitment and focus on the team.  And I’ve never seen a team that had the power to kick non-performers out on their own.  What I propose is to evaluate individuals, but to emphasize team support and commitment in the evaluation.

Continue reading

Share

by ·0 Comments

It’s easy to say that many skills are like riding a bicycle; that you never forget them, and can just start using them again after a long period of disuse.  It’s a lot harder to actually do it.  This is especially true when you try to keep track of several closely related skills.  For instance, I’ve learned so many computer programming languages, that when I need to learn a new one, it’s faster to see how it’s different than one I already know than to try to learn the language itself.  I’m sure the same is true of other fields.

When “Jacks of all trades” (I hate the term “generalist”) like myself job hunt, there’s usually a list of possible technologies and environments we’re willing to work in, so we can’t afford to just keep up on Java, or Perl, or PHP, or .NET.  We not only need to keep sharp on all of these, but we need to keep track in our heads which is which (after all many programming languages are very similar).  No matter how long you’ve used a skill, a few months of unemployment can blur the details.  In this post I plan to cover some helpful techniques for being ready for the technical interview or test without flipping through 300-page books each time.  I will not be addressing mastering new skills, because that is an entirely different activity.  Some of them may be specific to software development, but I hope there are parallels in other areas.

Like many job hunting activities, you shouldn’t wait until you’re job hunting to start doing them.  After all, you want to keep marketable on skills you’re not currently using at your current job, right?

Continue reading

Share