Why We Are Starting a Book Club

Health-eFilings Engineering has started a book club.  We won't be discussing War and Peace, or the latest from J.K. Rowling, but some good, old-fashioned non-fiction.

I was excited to hear this proposal for a few reasons:

Growth as an organization

It's important for a company, particularly a startup, to hire talented people.  It's even more important for those talented people to refine their craft, and raise their performance and that of the whole team.

Positive peer pressure on each other to improve our skills

We've all decided to learn something, but never found time to do it.  Or burn out after a quick start.  Having the team learn together means deadlines, which means pressure, which means it's˙easier to fit into our busy schedules.

Spending more time together on not strictly work-related activities

Our team is fun to work with, but being remote, we don't get many chances to do anything but work together.  Here is a great chance for us to do something other than work together, which will help bring us together.

Discussion leading to deeper understanding and better retention

Looking at my bookshelf, I see many texts that I've read, but can't tell you much about.  Not that I didn't pay attention while reading them, just that data has been overwritten.  The fact that we will be discussing these books will make us pay closer attention, take notes, and think about the material after reading it.  I hope this will not only deeper understanding of the material, but also to better retain it.

For our first book, we are reading Haskell Programming from First Principles.  We met last week to cover Chapter 1, Lambda Calculus.  Our discussion covered a number of topics, including:

Why Lambda Calculus is Important

We discussed how Haskell is really an implementation of a typed Lambda Calculus.  Besides, the authors warn us not to skip this chapter.  We also discussed how the chapter was originally not part of the book, but was added after the authors had feedback.

Syntax of Lambda Calculus

We discussed how the syntax in chapter 1 uses a confusing a mix of mathematical syntax and non-mathematical expressions.  This particularly gets confusing when switching from expressions like x + 1 and xx, which is not "X times X".  Adjacency, instead means "function application" in lambda calculus.

Next we discussed how everything after the head is right-associative.  This, in particular, cleared up a bit for me.  Though I was confused by whether parentheses change the order of operations or indicate a division between a function and its arguments.

Combinators

We reviewed combinators, discussed the S, K, and I combinators, and how they are all that is needed to build a Turing machine.  Though not explicitly mentioned in chapter 1, we discussed the Y combinator, how it is used to allow recursion using anonymous functions.  Overall, it isn't very clear, and requires one to reduce it on their own to understand it.

Beta Reduction

Probably the simplest topic we covered.  We discussed how the wording of "Applying a function to an argument" vs. our understanding of "Applying arguments to a function".  Did I mention I have an imperative programming background?

Divergence

We discussed whether or not divergence is a practical outcome in calculation, and where it could occur.  One example is iterative calculations with no exit condition.  In Haskell, the idea of lazy evaluation, of an infinite list is like divergence, but a filter can be applied to limit it to a finite set.

Next we will be covering Chapter 2, Hello Haskell (and perhaps Chapter 3).  If you are learning Haskell, consider reading Haskell Programming from First Principles, and learning along with us.

About the author:

Jeff Schmitz is a Software Engineer for Health-eFilings with a passion for Ruby and an interest in Haskell since seeing the quicksort implementation.

 

How the Theory of Sponsored Mobility Predicts Your Career Success

One thing which has shaped my view of career progress, and informed how we treat people at Health eFilings, is the notion of “sponsored-mobility”:

the sponsored-mobility perspective suggests that established elites pay special attention to those members who are deemed to have high potential and then provide sponsoring activities to them to help them win the competition. Thus, those who have early successes are more likely to receive sponsorship, and those who do not are likely to be excluded from such support activities. Once identified as potential elites, the chosen individuals are given favorable treatment to make them even better and differentiate them even further from the non-elite group. - Predictors of Objective and Subjective Career Success: A Meta Analysis 

The insight of the sponsored mobility model is that career progress is cumulative. Suppose you have two people, and one of them has a 1% higher GPA in high school. That better person might get into a 5% better college, which gives them a 10% better first job, which leads to a 20% better second job,… and 40 years later they are 10 times more successful than their fellow alumni, all because of that 1% initial advantage.

This means that it’s crucial for your employer to “sponsor” you. If you feel like your boss doesn’t appreciate you that’s not just a short-term headache – that means that your boss is going to pass you up for training opportunities, which will cause you to miss promotion opportunities, which will cause you to miss even more learning… it will have a permanent impact on your career success.

The aforementioned article did a meta-analysis on which factors predict a higher salary; a sample of these results is below (0 is no correlation, 1 is perfect correlation):

PredictorCorrelation with salary
Training and skill development opportunities0.24
Career sponsorship0.22
Being male0.18
Being white0.11
Proactivity0.11
Conscientiousness0.07

You can see that this is not just a hypothetical thought experiment – career sponsorship is more important than personality traits people often assume are relevant to career success like proactivity and conscientiousness.

For Health eFilings, this has led me to continually ask “how can I sponsor my team members?” How can we take someone that used to be getting 10% better per year and move them to getting 20% better per year? 50%? 100%?

One piece of the answer is Pearson’s Law: “That which is measured improves. That which is measured and reported improves exponentially.”

Do you know what your boss thinks of you? How does that compare to her impression of you last month? Are you getting more things done than you used to? Are you able to handle bigger projects? Is your defect rate going down? Are your communication skills getting better?

Everyone here who reports to me has a biweekly record of their progress in areas which are important to them and the company, and they can see themselves improving. I spend a significant fraction of my time doing this, but it’s completely worth it.

If you aren’t somewhere where you are receiving regular feedback about your progress, I would encourage you to think about what you can do to fix the problem. The management of your organization may be receptive to changing things, and if not, we are always hiring.

Questions To Ask A Prospective Startup Employer

I interview a lot of software engineers. Some of them are good, some of them aren't. I do see a general trend that engineers who work for startups are disproportionately likely to have certain gaps in their knowledge. This article lays out those gaps, why I think they occur, and gives questions engineers can ask their prospective employers to ensure that they don't end up with these gaps.

Deliberate Practice

A basic premise of this article is that not all types of practice are equally valuable. A particularly valuable type of practice is known as deliberate practice, and will usually involve:

  • Regular and immediate feedback
  • Practicing skill "chunks", instead of the entire skill
  • Practicing at the edge of your comfort zone

I think a lot of startups are unusually bad at allowing people to have deliberate practice, and this article will explain why.

Discount Rates

Would you rather have one dollar in revenue today, or $10 in revenue next year? I think startup founders are unusually likely to prefer the one dollar today, and they are correct to do so.

A more relevant form of discounting comes with technical debt: would you rather spend an hour coding things the right way today, or 10 hours fixing your problems next year?

As a startup, it's not at all uncommon to have a single prospective customer which will increase your revenue by an order of magnitude. Throwing a bunch of crap together to quickly prepare for a demo which will fall apart 10 seconds after the customer leaves the room is exactly the right decision to make: if that demo going well means that you will have an extra $100,000 in revenue; accruing technical debt that will cause future engineers to spend 500 extra hours fixing bugs is a lower cost than the benefit of the additional revenue.

All too often in startups the "rational" discount rate is actually infinite: if you will go bankrupt unless some deal goes through, you should throw everything at that deal regardless of what it will cost you in the future.

This amount of discounting is problematic for deliberate practice. People aren't going to do code reviews, because it's much better to just get something in quickly even if it breaks in the future. And forget performance reviews – your five year career plan is peanuts compared to the imminent bankruptcy of the company.

Questions to Ask Prospective Employers

  • What fraction of your pull requests get a code review? In what circumstances do you skip code reviews?
  • How frequently do you do performance reviews and what is involved in that process?

Technology Choices

There seems to be pretty widespread agreement among database experts that you should never use Mongo. Yet Mongo still seems to be the most popular database choice for startups.

There are some extreme examples of companies going bankrupt because Mongo doesn't support what is literally the first example in any database textbook of ACID-compliance, but for most startups I think the use of Mongo just results in late nights for the development team when data gets lost and a bunch of wasted time trying to force schemas on a schema-less database.

If your application requires user input, you will learn approximately 30 seconds into your career that the user cannot be trusted to enter actual dates into a date field. 45 seconds into your career you will learn that the solution to this problem is to use some sort of schema/type system to set the type of that field as "date" and there the learning stops.

But schema-less databases force you to practice over and over the skill of sanitizing user input – a skill you have already maxed out. All this time is wasted from the perspective of your career growth.

And even if you are learning things, it's questionable how valuable those skills are. I often worry that we are creating a generation of engineers who are experts at anti-patterns like duplicating data so that they don't have to do joins.

Mongo is an easy thing to pick on, but in general startups seem unusually likely to choose technologies because they're trendy and not because they're actually useful.

Questions to Ask

  • How strong is your database schema? Do you use a statically typed language? Why or why not?
    • (One major reason people use weak schemas and type systems is that it allows you to prototype and move faster at the beginning, even though it costs you more time fixing errors later on. This may be an appropriate trade-off for them to make, but you should be aware of their decision.)
  • Why did you choose your current technology stack?
    • Better answers will show that they actually understood the trade-offs they were making

 

Team Composition

A lot of engineers seem to think it looks good on their resume to go straight out of college and get a title like "vice president" or "chief technology officer". And who knows, maybe there are employers out there who are dumb enough to find those titles impressive. But if you are the most experienced person on your team – particularly if you don't have very much experience yourself – that doesn't bode well.

Firstly, if the company is running out of money, your investors are screaming at you to move faster and your customer complaints are piling up, it takes a lot of skill to figure out which corners you can cut and which ones you can't. Unless the leadership team has a lot of experience (and a strong backbone), the company's effective discount rate will be extremely high and it will accrue technical debt at an astonishing rate. "Employee growth" is usually the first thing to go in these scenarios.

Secondly, n important part of deliberate practice is finding skill "chunks" and practicing just those chunks at the edge of your comfort zone. Maybe the chunk you want to practice is scaling SQL queries. A good way to do that is to spend two weeks doing nothing but re-factoring old queries to run faster. A bad way is to spend two weeks working on what the company feels is the highest priority while reading SQL blog posts in your free time. But if you are on a small team, and particularly if you are the most senior person on that small team, it's going to be very hard for you to spend two weeks working on things which aren't the company's immediate priority.

Lastly, power corrupts. We've all written methods whose cyclomatic complexity compares favorably to the size of the national debt, and without someone there to throw up on your code you're probably not going to refactor. Over time, writing complex code will become your default way of doing things.

Questions to ask

  • Who is the most senior member of the team and what is their experience?
  • I want to learn _____. How will I be able to do this at your company? Can you give an example of someone who worked on a project for learning purposes and how it went?
  • What fraction of time do engineers spend re-factoring as opposed to creating new functionality?

Conclusion

Short-sighted leadership, stupid technologies and bad coworkers are things to worry about at any company, large or small. I would recommend asking these questions to any prospective employer.

But particularly if you are planning to work for a startup, I would encourage you to dig deep into these areas and not just assume that the leadership team knows what they're doing.

At Health eFilings we have spent a lot of time fixing these problems to provide a good learning environment for engineers, and we are hiring.