A Nation Defined by White Supremacy, Revisited

I had a Twitter conversation that was (remarkably) all light and no heat today related to the work of Ta-Nehisi Coates.  Before jumping into the particulars of today’s conversation however, I will begin with something I wrote to Andrew Sullivan a few years ago in response to one of his posts on an earlier work of Coates’:

Even those born and raised here do not always readily grasp the “racial resonances” you write of. I’m a 40-year black man who was born and raised in the suburbs, to parents who came here from Jamaica. That upbringing shaped my view of the United States into one that may share many characteristics with other immigrants to this country. I was raised to see this country as a place where you could accomplish whatever you wanted if you worked hard, studied hard, and did well in school. I had that luxury because of the environment my parents created, despite the fact that they didn’t have much money.

That’s where the problem with using a term like “culture of poverty” comes in. Such a term assumes that a group of people thinks and behaves in the same way because they are poor. Not very far under the surface of that assumption is the older, uglier one that those who are poor are somehow less industrious, moral and virtuous than those who are not. There is an intellectual laziness in the use of that term. It’s an attempt to shift responsibility from government institutions who have done very little to prevent the continued shrinkage of the middle class in general (and blacks in particular).

Whether you call it pessimism or gloom, I would not be so quick to brand it as out of place. Growing income inequality is a quantifiable reality, as is the increasing lack of economic mobility. It is difficult to believe that decades of government policy that tax investment at significantly lower rates than wages (under presidents of both parties) don’t play some role in that. For all the real progress this country has made, whether we have a black president or not, the United States is still a country where one political party actively strives to make it harder for citizens of color to exercise their right to vote. It is also still a country where someone at a hotel can assume I’m a valet (instead of a guest) or ask me if I’m a chauffeur when they see me parking my wife’s luxury car. My hope for a better future is paired with an awareness that only concrete actions will bring that better future about – and that my actions alone are not sufficient. The majority of society needs to see the advancement of minorities as somehow in their interest in order for lasting and sustainable change to occur.

Surprisingly (at least to me), Mr. Sullivan saw fit to publish my email to him in full here, along with a multitude of other thoughtful response that are well-worth reading.  Fast-forwarding from March 2014, to the present, I felt compelled to join a Twitter thread when Professor Jason D. Hill’s “An Open Letter to Ta-Nehisi Coates” showed up in my Twitter feed for the second time in the span of two weeks.  I first encountered it in a retweet from Ayaan Hirsi Ali, who called Hill’s commentary an “antidote to the racial poison spread by Ta-Nehisi Coates”.  I’ll revise and extend the remarks I made on Twitter since I’m not bound by character limits.  The questions that prompted this response are “Is there any critic of Ta-Nehisi Coates you find legit? Are all his critic naive, ignorant or racists?”:

I’ve read this (Hill’s) critique of Coates and found it interesting because both my parents are Jamaican so I share Mr. Hill’s culture.  While I agree that Mr. Hill makes his argument in good faith, I must note that I was referred to it by a tweet from Ayaan Hirsi Ali, who accused Coates of spreading racial poison as if merely pointing out the ways racism has affected black people was somehow worse than those who actually engaged in racist behavior.  This is just one example of the ways that someone who is trying to make an honest critique of Coates work can have that work hijacked for far less noble purposes.  I wish that black people who originate from the Caribbean, or directly from the continent of Africa would at least acknowledge that the African-American experience in this country can be different (if not far worse) than for immigrants of color.

Jamaicans and Africans of a certain age share experiences of seeing successful people who look like them at all levels.  In some cases, those successful people were their friends and family members, so expectations for them were similarly high–particularly in the area of education.  If I take my own family as an example, all four of us (father, mother, sister and myself) have completed master’s degrees (operations research, psychology, community counseling, business administration).  But we are underachievers compared to some of my relatives.  Three of my first cousins have doctorates (political science, environmental engineering, pharmaceutical chemistry), and a fourth earned full ride plus a stipend to Yale to pursue a Ph.D in music (after earning a master’s at the University of Maryland).  I don’t doubt that some African-Americans have had similar experiences, but I suspect that far too many have not.

Some will disagree, but I would argue that Jamaicans benefit in part from “model minority” perceptions in the same way other immigrants do–including those Mr. Hill references in his piece (a man from Vietnam, women from Trinidad, Iran, and Guatemala, and a man from India).  While you can certainly find negative stereotypes of Jamaicans in popular culture (crappy movies like Marked for Death or better shows like Power), you can just easily find more positive (or at least amusing) depictions as well (the Headley family in multiple skits on In Living Color, the movie Cool Runnings, etc).

It is possible to share positive experiences with and of America as a person of color without invalidating the negative experiences of others.  Unfortunately, Professor Hill’s essay fails in this task, as have the vast majority of the critics of Coates work.  The related way in which most critiques of Coates’ work fail is in their inability or unwillingness to acknowledge that the progress this country has made in how it treats people of color in this country has included setbacks and retreats.  Given that our current president holds that position in large part because of his consistent, multi-year denial that our previous president was a citizen of this country, a critique that fails to grapple with this fact even in passing is incomplete to say the least.

Chidike Okeem is the only writer I’ve encountered thus far who has succeeding in writing thoughtful critiques of Coates’ work as well as advocating for a conservatism that is divorced from the intellectually-lazy Trumpism that seems to represent mainstream conservatism today.  It is to his credit he admires one of Jamaica’s most prominent historical figures, Marcus Garvey.

It occurred to me after I’d finished my Twitter thread that perhaps another reason that many critiques of Coates work tend to fall short for me is that they tend to argue solely from anecdote.  Coates is hardly averse to use anecdotes in his work, but he incorporates history and real scholarship into his work in a way that few of his critics seems willing or able to match.  Sullivan was calling Coates a pessimist in 2014, before Trump’s successful candidacy and the spectacle of tiki torch-bearing white supremacists using monuments to the Confederacy as rallying points to spread their hateful vision.  If critiques of the work of Coates are going to be constructive and useful, they need to engage with this reality and discuss ways forward that will steer us away from “learned helplessness” or despair.

How I’m Handling My Layoff (Part 2)

Recap

My previous blog post on this subject covered unemployment insurance, an early intervention workshop, networking, and job fairs.  In this post, I’ll cover online courses, coding exercises, interview preparation, and some observations about the various sites available to apply for jobs.

Online Courses

One of the recommendations I received both in the early intervention workshop and at the job fairs I attended was to pursue certifications in order to increase my marketability.  I’m a Certified Scrum Master by virtue of a two-day training course and exam from an excellent coach at FoxHedge Ltd. The Project Management Professional (PMP) certification is in far more demand however, so I began looking for courses to help me pursue it.  My sister let me know of some free, instructor-led online courses available through my county library.  Only a library card is needed to access a wide variety of project management courses.  I wish I had discovered this while I was still working, because the length and pace of the PMP Prep I course that I took was well-suited to be taken in the evening after work (instead of the cramming that is apparently typical of far more expensive commercial prep courses).

Beyond pursuing certifications, reinforcing skills in current technologies and building new ones is another avenue I’m taking.  For Microsoft-specific technologies (where the bulk of my experience lies), the Microsoft Virtual Academy is a great resource.  Microsoft already provides a ton of free online documentation, code samples and other resources, but the instructor-led content of the virtual academy structures things in a more directed fashion.  Another source of free courses is edX, though I haven’t taken any courses there yet.

Another source for online courses that I took advantage of both before and after the layoff was Udemy.  A junior developer on my staff recommended it and the course I took on her recommendation (Spring and Hibernate for Beginners) is really well done.  Udemy has regular sales on courses, offering them for $10 or $15 instead of the hundreds they would normally cost, which is a great value–especially when you consider that you’re buying permanent access to the course material.  Pluralsight is another great source of courses that offers access to all of their courses for a monthly or annual fee for individuals instead of selling each course stand-alone.

Coding Exercises

I’m discussing coding exercises separately from interview preparation because they have a value above and beyond just interview preparation.  By providing problems disconnected from the ones you might normally encounter in the context of work, the exercises sharpen your problem-solving skills as well as getting you to write code.  I initially joined Hackerrank because a job opening I applied for used an exercise there as their initial screen.  While I didn’t ace that exercise, I tried others and enjoyed them.  Working on these sorts of exercises is one of a few practices I plan to continue after I find a new employer.

Interview Preparation

The early intervention workshop I mentioned in the previous post provided a lot a useful advice about both phone and in-person interviews.  The use of Skype video has proven to be a lot more common in my most recent job search, so dress code advice applies more often than before.  Another source of interviewing advice that I found useful was a book titled Cracking the Coding Interview, by Gayle Laakman McDowell.  Her advice is tailored for interviewing at companies like Amazon, Facebook, Google, and Microsoft but prepares you well for interviews with other companies that have rigorous interview processes.  Quite a few of the in-person interviews I’ve had so far required writing the solution to a coding exercise on a whiteboard, so McDowell’s advice to practice on paper has proven valuable.

Preparing for the “soft skills” part of the interview is easy to overlook but is just as important as demonstrating technical ability.  The early intervention workshop provided great advice about structuring success stories of your work experience in advance of the interview.  I combined this advice with McDowell’s interview preparation grid guidance so that the information at hand for phone interviews and for review in advance of in-person interviews.  One or more in-person behavioral interviews as part of the process seems to be a popular trend with companies these days.  When I was helping my previous employer staff up a project, conducting behavioral interviews was part of my role.

Mock/practice interviews help a great deal.  Particularly if your mock interviewer has a technical background, they can provide challenging questions and in-depth feedback on how your answers might be perceived.  If someone can mock interview you in-person, you can also get feedback on your body language and facial expressions that will help.

Job Sites

There are tons of sites where you can look for jobs, so I’m limiting my discussion of these sites to three that I like and one I don’t.  I highly recommend Stackoverflow Careers for finding good hands-on development openings.  I particularly like their Developer Story feature for the way it displays your work experience, certification(s) and GitHub contributions in a chronological fashion.  Google recently added a specific job search capability to their search engine that offers a lot of control over filtering and alerts for opportunities you’re interested in.  Indeed.com is another site with good search/filtering capabilities (including filtering by salary).  One site that that multiple people recommended to me but that I didn’t have a good experience with was hired.com.  I don’t know if it’s a mismatch between my skillset and the needs of companies on Hired in the DC/metro area, but multiple 2-week availability cycles on Hired yielded just one phone interview with no follow-up.

What’s Next?

In my next post on this subject, I’ll talk about recruiters.

How I’m Handling My Layoff (Part 1)

Introduction

Earlier this summer, I was laid off from my job as a software development manager.  The reasons are less important than how I’ve spent my time since, and what I’ve learned (and am continuing to learn) as a result.  This post will cover what I’ve learned so far and what I would do differently if I had it to do all over again.

Unemployment Insurance

When filing for unemployment insurance, be sure to file in the state or jurisdiction where you were most recently working.  In my case, the jurisdiction of my former employer’s headquarters differed from that of the clients I’d done work for on their behalf.  So when I filed for unemployment with Virginia, my claim was rejected because their system showed no record of my having earned income there. Once I filed with the state of Maryland (the jurisdiction of the client I’d done the most work for), their records showed my income earned and I was deemed eligible for the maximum amount they pay out per week (an amount that at least as of this writing is the most generous of the 3 jurisdictions that make up the DMV).
Speaking of payments, the state of Maryland asks you to choose whether or not to have federal and state taxes withheld from your benefit.  I opted to have the taxes withheld, and in retrospect this was a mistake.  I incorrectly anticipated a quick return to the workforce and minimal disruption in my income.

Early Intervention Workshop

Once I’d been unemployed for about a month, I received a notice to attend a required workshop.  I live in Montgomery County and fortunately the location of the full-day workshop was close enough to where I live that I could get there easily.  I was dubious of the utility of such a workshop but it turned out to be very useful.
The most useful aspect of the workshop (beyond the information shared by the instructor, which was excellent) was the opportunity to network with other people who were unemployed.  Those who attended the workshop with me were at various stages in a variety of different careers including law, IT, sales, marketing, and teaching.  Beyond connecting with some of the on LinkedIn, we’ve been in touch by phone and gotten referrals to different recruiters.

Networking

If there is anything I would do differently when it came to handling this layoff, it would be to have my own business cards ready in advance.  While I was able to write down contact information for people I met during the ROW workshop, it would have been much easier to be able to hand out business cards.  Soon after the workshop was done, I jumped on vistaprint.com and ordered some business cards with my name, phone number and the URL for my LinkedIn profile on them.  They came in handy when I was invited to a couple of job fairs.

Job Fairs

I received an invite on LinkedIn to attend reStart Hiring events both in the BWI area and in northern Virginia.  While they’re targeted at primarily at people with DOD clearances, my civilian agency and DHS EOD (entrance-on-duty) clearances were sufficient to enable me to attend.
At both events, I did my best to speak with as many different companies as possible—even those who didn’t have a position for me that matched my skillset.  One of the recruiters I met was kind enough to pass along my résumé to her husband, who referred me for a role with his employer.  Two of the job fair attendees I encountered were able to refer me to openings at companies they were aware of.  A third was able to provide advice on a training course for PMP certification.

What’s Next

My next post on this subject will cover online courses, coding exercises, and interview preparation (among other topics).

Nulls Break Polymorphism, Revisited

Steve Smith wrote this post regarding the problem with null about two years ago.  It’s definitely worth reading in full (as is pretty much anything Steve Smith writes).  The post provided code for the implementation of an extension method and a change in the main code that would address null without throwing an exception.  It also mentioned the null object design pattern but didn’t provide a code example.

I took the code from the original post and revised it to use the null object design pattern.  Unlike the original example, my version of the Employee class overrides ToString() instead of using an extension method.  There are almost certainly any number of other tweaks which could be made to the code which I may make later.

Smith’s post links additional material that’s also worth checking out:

Thoughts on the Damore Manifesto

I’ve shared a few articles on Facebook regarding the now infamous “manifesto” (available in full here) written by James Damore.  But I’m (finally) writing my own response to it because being black makes me part of a group even more poorly represented in computer science (to say nothing of other STEM fields) than women (though black women are even less represented in STEM fields).

One of my many disagreements with Damore’s work (beyond its muddled and poorly written argument) is how heavily it leans on citations of very old studies. Even if such old studies were relevant today, more current and relevant data debunks the citations Damore uses. To cite just two examples:

Per these statistics, women are not underrepresented at the undergraduate level in these technical fields and only slightly underrepresented once they enter the workforce.  So how is it that we get to the point where women are so significantly underrepresented in tech?  Multiple recent studies suggest that factors such as isolation, hostile male-dominated work environments, ineffective executive feedback, and a lack of effective sponsors lead women to leave science, engineering and technology fields at double the rate of their male counterparts.  So despite Damore’s protestations, women are earning entry-level STEM degrees at roughly the same rate as men and are pushed out.

Particularly in the case of computing, the idea that women are somehow biologically less-suited for software development as a field is proven laughably false by simply looking at the history of computing as a field.  Before computers were electro-mechanical machines, they were actually human beings–often women. The movie Hidden Figures dramatized the role of black women in the early successes of the manned space program, but many women were key to advances in computing both before and after that time.  Women authored foundational work in computerized algebra, wrote the first compiler, were key to the creation of Smalltalk (the first object-oriented programming language), helped pioneer information retrieval and natural language process, and much more.

My second major issue with the paper is its intellectual dishonesty.  The Business Insider piece I linked earlier covers the logical fallacy at the core of Damore’s argument very well.  This brilliant piece by Dr. Cynthia Lee (computer science lecturer at Stanford) does it even better and finally touches directly on the topic I’m headed to next: race.  Dr. Lee notes quite insightfully that Damore’s citations on biological differences don’t extend to summarizing race and IQ studies as an explanation for the lack of black software engineers (either at Google or industry-wide).  I think this was a conscious omission that enabled at least some in the press who you might expect to know better (David Brooks being one prominent example) to defend this memo to the point of saying the CEO should resign.

It is also notable that though Damore claims to “value diversity and inclusion”, he objects to every means that Google has in place to foster them.  His objections to programs that are race or gender-specific struck a particular nerve with me as a University of Maryland graduate who was attending the school when the federal courts ruled the Benjamin Banneker Scholarship could no longer be exclusively for black students.  The University of Maryland had a long history of discrimination against blacks students (including Thurgood Marshall, most famously).  The courts ruled this way despite the specific history of the school (which kept blacks out of the law school until 1935 and the rest of the university until 1954.  In the light of that history, it should not be a surprise that you wouldn’t need an entire hand to count the number of black graduates from the School of Computer, Mathematical and Physical Sciences in the winter of 1996 when I graduated.  There were only 2 or 3 black students, and I was one of them (and I’m not certain the numbers would have improved much with a spring graduation).

It is rather telling how seldom preferences like legacy admissions at elite universities (or the preferential treatment of the children of large donors) are singled out for the level of scrutiny and attack that affirmative action receives.  Damore and others of his ilk who attack such programs never consider how the K-12 education system of the United States, funded by property taxes, locks in the advantages of those who can afford to live in wealthy neighborhoods (and the disadvantages of those who live in poor neighborhoods) as a possible cause for the disparities in educational outcomes.

My third issue with Damore’s memo is the assertion that Google’s hiring practices can effectively lower the bar for “diversity” candidates.  I can say from my personal experience with at least parts of the interviewing processes at Google (as well as other major names in technology like Facebook and Amazon) that the bar to even get past the first round, much less be hired is extremely high.  They were, without question, the most challenging interviews of my career to date (19 years and counting). A related issue with representation (particularly of blacks and Hispanics) at major companies like these is the recruitment pipeline.  Companies (and people who were computer science undergrads with me who happen to be white) often argue that schools aren’t producing enough black and Hispanic computer science graduates.  But very recent data from the Department of Education seems to indicate that there are more such graduates than companies acknowledge. Furthermore, these companies all recruit from the same small pool of exclusive colleges and universities despite the much larger number of schools that turn out high quality computer science graduates on an annual basis (which may explain the multitude of social media apps coming out of Silicon Valley instead of applications that might meaningfully serve a broader demographic).

Finally, as Yonatan Zunger said quite eloquently, Damore appears to not understand engineering.  Nothing of consequence involving software (or a combination of software and hardware) can be built successfully without collaboration.  The larger the project or product, the more necessary collaboration is.  Even the software engineering course that all University of Maryland computer science students take before they graduate requires you to work with a team to successfully complete the course.  Working effectively with others has been vital for every system I’ve been part of delivering, either as a developer, systems analyst, dev lead or manager.

As long as I have worked in the IT industry, regardless of the size of the company, it is still notable when I’m not the only black person on a technology staff.  It is even rarer to see someone who looks like me in a technical leadership or management role (and I’ve been in those roles myself a mere 6 of my 19 years of working).  Damore and others would have us believe that this is somehow the just and natural order of things when nothing could be further from the truth.  If “at-will employment” means anything at all, it appears that Google was within its rights to terminate Damore’s employment if certain elements of his memo violated the company code of conduct.  Whether or not Damore should have been fired will no doubt continue to be debated.  But from my perspective, the ideas in his memo are fairly easily disproven.

Entity Framework Code First to a New Database (Revised Again)

As part of hunting for a new employer (an unfortunate necessity due to layoffs), I’ve been re-acquainting myself with the .NET stack after a couple of years building and managing teams of J2EE developers.  MSDN has a handy article on Entity Framework Code First, but the last update was about a year ago and some of the information hasn’t aged so well.

The first 3 steps in the article went as planned (I’m using Visual Studio 2017 Community Edition).  But once I got to step 4, neither of the suggested locations of the database worked per the instructions.  A quick look in App.config revealed what I was missing:

Once I provided the following value for the server name:

(localhostdb)\mssqllocaldb

database I could connect to revealed themselves and I was able to inspect the schema.  Steps 5-7 worked without modifications as well.  My implementation of the sample diverged slightly from the original in that I refactored the five classes out of Program.cs into separate files.  This didn’t change how the program operated at all–it just made for a simpler Program.cs file.  The code is available on GitHub.

Podcast Episodes Worth Hearing

Since I transitioned from a .NET development role into a management role 2 years ago, I hadn’t spent as much time as I used to listening to podcasts like Hanselminutes and .NET Rocks.  My commute took longer than usual today though, so I listened to two Hanselminutes episodes from December 2016.  Both were excellent, so I’m thinking about how to apply what I’ve heard directing an agile team on my current project.

In Hanselminutes episode 556, Scott Hanselman interviews Amir Rajan.  While the term polyglot programmer is hardly new, Rajan’s opinions on what programming languages to try next based on the language you know best were quite interesting.  While my current project is J2EE-based, between the web interface and test automation tools, there are plenty of additional languages that my team and others have to work in (including JavaScript, Ruby, Groovy, and Python).

Hanselminutes episode 559 was an interview with Angie Jones.  I found this episode particularly useful because the teams working on my current project include multiple automation engineers.  Her idea to include automation in the definition of done is an excellent one.  I’ll definitely be sharing her slide deck on this topic with my team and others..

Best Practices for Software Testing

I originally wrote the following as an internal corporate blog post to guide a pair of business analysts responsible for writing and unit testing business rules. The advice below applies pretty well to software testing in general.

80/20 Rule

80% of your test scenarios should cover failure cases, with the other 20% covering success cases.  Too much of testing (unit testing or otherwise) seems to cover the happy path.  A 4:1 ratio of failure case tests to success case tests will result in more durable software.

Boundary/Range Testing

Given a range of valid values for an input, the following tests are strongly recommended:

  • Test of behavior at minimum value in range
  • Test of behavior at maximum value in range
  • Tests outside of valid value range
    • Below minimum value
    • Above maximum value
  • Test of behavior within the range

The following tests roughly conform to the 80/20 rule, and apply to numeric values, dates and times.

Date/Time Testing

Above and beyond the boundary/range testing described above, the testing of dates creates a need to test how code handles different orderings of those values relative to each other.  For example, if a method has a start and end date as inputs, you should test to make sure that the code responds with some sort of error if the start date is later than the end date.  If a method has start and end times as inputs for the same day, the code should respond with an error if the start time is later than the end time.  Testing of date or date/time-sensitive code must include an abstraction to represent current date and time as a value (or values) you choose, rather than the current system date and time.  Otherwise, you’ll have no way to test code that should only be executed years in the future.

Boolean Testing

Given that a boolean value is either true or false, testing code that takes a boolean as an input seems quite simple.  But if a method has multiple inputs that can be true or false, testing that the right behavior occurs for every possible combination of those values becomes less trivial.  Combine that with the possibility of a null value, or multiple null values being provided (as described in the next section) and comprehensive testing of a method with boolean inputs becomes even harder.

Null Testing

It is very important to test how a method behaves when it receives null values instead of valid data.  The method under test should fail in graceful way instead of crashing or displaying cryptic error messages to the user.

Arrange-Act-Assert

Arrange-Act-Assert is the organizing principle to follow when developing unit tests.  Arrange refers to the work your test should do first in order to set up any necessary data, creation of supporting objects, etc.  Act refers to executing the scenario you wish to test.  Assert refers to verifying that the outcome you expect is the same as the actual outcome.  A test should have just one assert.  The rationale for this relates to the Single Responsibility Principle.  That principles states that a class should have one, and only one, reason to change.  As I apply that to testing, a unit test should test only one thing so that the reason for failure is clear if and when that happens as a result of subsequent code changes.  This approach implies a large number of small, targeted tests, the majority of which should cover failure scenarios as indicated by the 80/20 Rule defined earlier.

Test-First Development & Refactoring

This approach to development is best visually explained by this diagram.  The key thing to understand is that a test that fails must be written before the code that makes the test pass.  This approach ensures that test is good enough to catch any failures introduced by subsequent code changes.  This approach applies not just to new development, but to refactoring as well.  This means, if you plan to make a change that you know will result in broken tests, break the tests first.  This way, when your changes are complete, the tests will be green again and you’ll know your work is done.  You can find an excellent blog post on the subject of test-driven development by Bob Martin here.

Other Resources

I first learned about Arrange-Act-Assert for unit test organization from reading The Art of Unit Testing by Roy Osherove.  He’s on Twitter as @RoyOsherove.  While it’s not just about testing, Clean Code (by Bob Martin) is one of those books you should own and read regularly if you make your living writing software.

Software Development Roles: Lead versus Manager

I’ve held the title of development lead and development manager at different points in my technology career. With the benefit of hindsight, one of the roles advertised and titled as the latter was actually the former. One key difference between the two roles boils down to how much of your time you spend writing code. If you spend half or more your time writing code, you’re a lead, even if your business cards have “manager” somewhere in the title. If you spend significantly less than half your time writing code, then the “manager” in your title is true to your role. When I compare my experience between the two organizations, the one that treats development lead and development manager as distinct roles with different responsibilities has been not only been a better work environment for me personally, but has been more successful at consistently delivering software that works as advertised.

A company can have any number of motivations for giving management responsibilities to lead developers. The organization may believe that a single person can be effective both in managing people and in delivering production code. They may have a corporate culture where only minimal amount of management is needed and developers are self-directed. Perhaps their implementation of a flat organizational structure means that developers take on multiple tasks beyond development (not uncommon in startup environments). If a reasonably-sized and established company gives lead and management responsibilities to an individual developer or developers however, it is also possible that there are budgetary motivations for that decision. The budgetary motivation doesn’t make a company bad (they’re in business to make money after all). It is a factor worth considering when deciding whether or not a company is good for you and your career goals.

Being a good lead developer is hard. In addition to consistently delivering high-quality code, you need to be a good example and mentor to less-senior developers. A good lead developer is a skilled troubleshooter (and guide to other team members in the resolution of technical problems). Depending on the organization, they may hold significant responsibility for application architecture. Being a good development manager is also hard. Beyond the reporting tasks that are part of every management role, they’re often responsible for removing any obstacles that are slowing or preventing the development team from doing work. They also structure work and assign it in a way that contributes to timely delivery of functionality. The best development managers play an active role in the professional growth of developers on their team, along with annual reviews. Placing the responsibility for these two challenging roles on a single person creates a role that is incredibly demanding and stressful. Unless you are superhuman, sooner or later your code quality, your effectiveness as a manager, or both will suffer. That outcome isn’t good for you, your direct reports, or the company you work for.

So, if you’re in the market for a new career opportunity, understand what you’re looking for. If a development lead position is what you want, scrutinize the job description. Ask the sort of questions that will make clear that a role being offered is truly a development lead position. If you desire a development management position, look at the job description. If hands-on development is half the role or more, it’s really a development lead position. If you’re indeed superhuman (or feel the experience is too valuable to pass up), go for it. Just be aware of the size of the challenge you’re taking on and the distinct possibility of burnout. If you’re already in a job that was advertised as a management position but is actually a lead position, learn to delegate. This will prove especially challenging if you’re a skilled enough developer to have landed a lead role, but allowing individual team members to take on larger roles in development will create the bandwidth you need to spend time on the management aspects of your job. Finally, if you’re an employer staffing up a new development team or re-organizing existing technology staff, ensure the job descriptions for development lead and development manager are separate. Whatever your software product, the end result will be better if you take this approach.

Getting (and Staying) Organized

During the past year-and-a-half as a software development manager for a local consulting firm, I’ve tried a number of different tools and techniques to keep me organized.  As my role expanded to include business development, hiring, and project management tasks, there’s been a lot more to keep track of.  I meet weekly or twice-monthly 1-on-1 with each team member on my current project.  “Move it out of e-mail” is my primary objective for getting organized.  The rest of this post will elaborate on the specific alternatives to e-mail that I tried on the way to my current “manager tools”.
Outlook
Beyond e-mail and calendar functionality, Outlook offers a To-Do List and Tasks for keeping organized.  Both provide start dates and due dates.  The To-Do List is tied directly to individual e-mails, while Tasks are stand-alone items.  I abandoned the use of task functionality pretty quickly.  I used the To-Do List as recently as July of this year, but I see it as a bad habit now.  I rarely end up clearly the various options to flag an e-mail for follow-up (Today, Tomorrow, This Week, Next Week, No Date & Custom), so they become an ever-growing list where I only very occasionally mark items as complete.  In addition, the search functionality in Outlook never works as well as I need it to when I’m trying to find something.
Lighthouse
Once I passed the six month mark with my employer, I felt comfortable enough to introduce weekly 1-on-1s as a practice on my project.  After a couple of weeks of filling out a paper template from these guys for each team member on my project, the need for a better solution became readily apparent.  Lighthouse is the name of the company and their product, a web-based application for managing your 1-on-1s with staff.  After the free trial, I chose not to renew.  While I like Lighthouse, and the cost wasn’t prohibitive, my employer wasn’t going to pay for it.
I liked the ideas in Lighthouse enough that I tried to build a simpler, custom version of it myself.  Increasing work responsibilities (and the birth of my twins, Elliott and Emily) erased the free time I had for that side project.  Lighthouse maintains a leadership and management blog that I’ve found to be worthwhile reading.
Trello
I first started using Trello years ago for something not at all related to work–requesting bug fixes and enhancements to a custom website my fantasy football league uses.  I didn’t consider using it for work until I was re-introduced to it by a VP who uses it to keep himself organized.  Once I reviewed a few example boards and set up a board to moderate weekly business development meeting, new possibilities for its use revealed themselves very quickly.  As of today, I’ve got 4 different boards active: 1 for “hiring funnel” activities, another board for business development tasks, a 3rd for project-specific tasks that don’t fall into a current Scrum sprint, and a 4th board as a general to-do list.  The last board turned out to be a great solution for capturing information from my 1-on-1 meetings.  It also tracks my progress toward annual goals, training reminders, and other “good corporate citizen” tasks.
The free tier of Trello service offers the functionality that matters most:
  • create multiple boards
  • define workflows as simple or complex as you need
  • create cards as simple or complex as you need
Markdown formatting, attachment support, due dates, checklists, archiving, the ability to subscribe to individual cards, lists and/or boards and collaborate with other team members of Trello combined with the key functionality above has helped me become much better organized and able to communicate more consistently with my team members and executives in my organization.  The search capability works much better for me than Outlook as well.
I’ve only gotten a handful of co-workers in my organization to adopt Trello so far, but I keep recommending it to other co-workers.  I’d like to see our entire business unit adopt it officially so we can take advantage of the capabilities available at the Business Class tier.