I am looking for Software Engineering Manager position in the Boston area, leading a team of (preferably) Java developers in an Agile environment. My strengths are my diversity and depth of experience, perseverance, ability to learn new technologies quickly, and communication and organizational skills. I’m happiest when I’m collaborating on hard problems, mentoring others, establishing best practices, and improving software. I’m a strong believer in the Agile philosophies and principles, and valuing quality and teamwork.
If you are looking for someone like me, or know someone who is, please contact me at email@example.com.
This article is about The Dev group in relation to other business units in the company. In this article, “the Dev group” is shorthand for whatever business unit the software development team is in (Technology, IT, …).
Many times in a company, the Dev group is seen not as a consumer of requirements and a provider of solutions, but as somehow subservient to other groups, like Marketing. The Dev group has to be very careful not to challenge their statements in meetings, and just accept that they know what they’re doing, no matter how little it’s based on actual customer feedback, or how SWAG the finance estimates are, or how much of their input is colored by personal bias. I’ve been taken off of meeting invites because I dared to challenge the statements about the Dev group and defending them from other business units. We even say things like “Let’s find out what The Business thinks of these features” as a short hand for “the other business units”. But phrasing it that way implies that the Dev group isn’t a separate but equal business unit.
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.
MVP stands for (in this article) Minimum Viable Product. It’s not an Agile concept. It’s not even a software-specific concept, though it’s certainly easier to do with software, since upgrading software is usually easier than upgrading hardware. The concept is simple: Instead of building every feature under the sun into your product then releasing it, build the least you think people will buy and release that, following up with more feature-rich versions. There are several good reasons to do this.Continue reading
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.
I heard a CEO say the other day that “Charity is not a business model”. I’m not so sure that’s the case, but it got me thinking. And researching. It turns out that companies (and their executives) are not legally bound to maximize shareholder profits, as many people (including myself, until now) think. Businesses can form to, and focus on, maximize any collection criteria they want.