As a manager, on-boarding is both tough and really important whether you’re joining a team or they’re joining yours. My very short list for on-boarding in either direction is:
- Share expectations
- Build trust
Gender Diversity in Tech Reading List
This collection of lists is predominantly skewed towards gender diversity in tech. I don’t mean to imply that racial diversity is less important, but this collection sprung out of discussions related to James Damore’s memo.
This article by Rachel Thomas touches on many of these issues (with citations), and I recommend it.
We have a problem with institutionalized sexism in (at least) the tech industry which reduces gender diversity. This has multiple aspects:
- Hiring. Male candidates receive more call-backs than female candidates. This may be due to expectation mismatches between female applicants and male screeners.
- Promotion. Women are assessed on their performance whereas men are assessed on their potential.
- Diversity efforts. Women and underrepresented groups are penalized for promoting diversity.
- Sexual harassment. Sexual harassment reports are often ignored, including when reported by women to women. Uber is not unique.
- Retention. Women leave tech 45% more frequently than men, but only 27% of time citing family as a reason.
Gender diversity in tech is important. Here are some reasons why:
- Economics. Higher diversity balanced companies have seen better financial returns. 15% for gender-balance, 35% for ethnicity-balance.
- Access to a wider hiring pool. There is a labor shortage with 627,000 open tech jobs as of April, 2017. Getting more women to apply to your jobs increases your odds of finding a great qualified candidate. 10,741 women graduated with Computer Science Bachelor’s degrees, 48,840 men in 2014-2015. Improving your funnel could increase your pool of candidates by 18%.
- Problem-solving. Diverse teams solve problems more quickly. Like in this study of cognitive diversity.
Are there any links I should add? Please let me know!
2016 in Review
Let me just start with: Wow.
It’s been a huge year for all of us, full of changes and growth.
Beginnings
At the beginning of the year, I was looking for a new job in software engineering management. My wife was 5 months pregnant, and I was trying to figure out how rapidly I needed to get a paycheck. I was very lucky to be able to sell some stock options from my last company to tide me over for six months and allow me to find the job I wanted rather than settling for the job I needed. That has not been my experience in the past, and I don’t count on it being the case in the future.
Finding a management job can be tough.
Feedback is a gift
“Ever Present” by JD Hancock is licensed under CC BY 2.0
I’ve heard that a lot this year and it’s changed me in two pretty fundamental ways.
First, I’ve started seeking it out.
Speak to Be Heard (Not to Win)
I just read Quinn Norton‘s excellent piece, Ahimsa Online and it got me thinking about arguing on the internet, and in my day-to-day. Continue reading “Speak to Be Heard (Not to Win)”
Testing Databases
I work with Oracle and MySQL on a daily basis, and one of the questions I’ve often met is: How do I test my database controllers? This post explores that question using Java, but the principles apply to any language.
Most of the time, you can mock your controllers away. For example, if you have code that retrieves a data set, performs some manipulation of that data, and then visualizes it, there are several tests to perform:
- Did the data retrieve correctly? (i.e. was your query correct?)
- Did the manipulation algorithm work correctly?
- Did the visualization work correctly?
(2) is the one that most people test through unit tests. Hopefully you can test your manipulation methods by passing in a testing data set and evaluating the resulting dataset. If necessary, you can replace your controller with a mock/stub so that you’re not actually hitting the database.
(3) is the one that usually gets picked up by UI integration tests with frameworks like Selenium, Jasmine/Jest, etc. These tests can be fragile as UI changes and are usually very slow, as they require full-stack latency (POST your request, wait for the server to respond, inspect the DOM, rinse and repeat).
(1) is one for which I’ve seen the least number of tests (outside of integration tests), but they have some undesirable expenses: you have to have access to a database, and the left-over data might screw you (or your co-worker) up later. Continue reading “Testing Databases”
Expectations Should Not be Kept to Yourself
I’ve been watching Sex and the City with my wife. I’d gotten her to watch a lot of other shows of my choosing: Breaking Bad, The Wire, Justified, and I thought I’d try something from her corner of the television universe. We blasted through all six seasons, alternating between HBO Go and the (very large) pink album of the complete series sitting on our shelf when our internet crapped out. We watched the first movie last night. There are a lot of lessons to be learned from that show, and most of them are of the “What not to do” sort.
[Spoiler alert!]
Last night, Carrie and Big were arguing about the size and impact of their nuptials.
Big angrily shouted “200 people! Page 6! Do you know how that makes me look?”
I shouted back at the TV (I do that): “No, because you don’t communicate your feelings with Carrie!”
In fairness, Carrie isn’t good at that either, but that brings me to my point: communication is key. Continue reading “Expectations Should Not be Kept to Yourself”
Not So SoftWare: Because Software Development Can Be Hard
Hi everyone,
My name is Matt Newkirk. I’m a software engineer and I build tools, mostly in Java, Perl, or Bash. Those are reasonably easy to create, maintain, and deploy.
I also help other engineers with their technical designs, testability, and code reviews. Installing a Perl tool is easy: yum or rpm can help you with that. Instilling better design is harder, though arguably more important.
This blog will be about both: software development (and management) practices, and parachute tools to get you home safely when those practices fail.
I hope you enjoy these forthcoming posts and that you’ll share your software development path with me as well!
Matt Newkirk's NotSoSoftware 