Engineering Named Things This is a cautionary tale. It's the story of an internal tool development project. We'll call it Astro, because naming things is hard, and the reasons why are very instructive.
Interviewing Interviewing Software Engineers Artificial white board programming tests are the wrong thing, but they're easy to assign. Doing the right thing is going to be harder. So what we really need to do is identify what we're looking for in a programmer
Interviewing Questions for your interviewer As a candidate, interviews are your chance to learn how the team works, and how the company views and treats their employees. But after enduring your own interview, it's hard to know what to ask or how to evaluate the answers. This should help.
Process Measuring Risk A while back, I was in a planning meeting where a whole development organization was trying to squeeze a huge and non-negotiable volume of work into a predetermined and non-negotiable release schedule. It
Process Software Engineer I am a software engineer. What I'm not is a programmer, or a developer, or a coder, or a ninja. Simply writing code is the easiest part of developing software. Anyone can write
Culture Some things I DO miss about big companies I previously discussed some things about working in a large organization that I was happy to be rid of. This is the other side of that coin. These things are by no means
Process A Bug's Life I've written before about useful metrics for software development organizations, and it's past time for another. The metric I'm proposing now, I call "A Bug's Life". Because who doesn't like Pixar?
Process A Note on the Daily Standup Apparently, (scrum) standup meetings are broken. It seems that way at least, because making suggestions for how to fix them seems to be a seminal favorite topic in programmer blogs; so it must
Process Software development metrics Software development is a skill. And for the moment, I mean that in an institutional sense. It's a skill the organization has. It's something that an organization can be good at. And it's
Process (How to) Be Solution Oriented There's a piece of advice I've often heard regarding being successful in your job. Actually there are a lot, but the one I'm think of is that you should not bring problems to
Testing Software Engineer in Test Update: I'm actually a Sofware Engineer now. But everything else holds up. I'm a software engineer, working mostly to support testing other software. I don't work at Google, but if I did, my
