Author Archives: Lou Franco

Add Developers to a Team Without Lowering Productivity

According to Brook’s Law (from Mythical Man Month [affiliate link]), adding software developers to a late project makes it later because the number of communication lines increases rapidly with each new person. A team with N developers has N*(N-1)/2 communication lines, so a team of two has one line between them, but a team of 20 has 190 lines, one for each pair. If we accept this, there are several caveats that mean the law might not apply to you.

It should be clear that this won’t apply to a very small team. If you have two developers, then adding two more will help. The number of communication lines goes from one to six, but the amount of time that can be spent working on the project doubles. Compare this to adding two people to a twenty person team, where you might add more than forty communication lines and only 10% more work time. Also, a team of two have probably not created a very large codebase yet, so ramp-up time is not as bad as what it takes to learn what a team of twenty could create.

Another way the law doesn’t apply is if your developers don’t need to talk to each other. If they can work completely independently, then you are not adding communication lines. That also works if they only need to talk to a small subset.

You can also increase the effectiveness of a given team (before adding anyone) if you can remove lines of communication. This does not mean “better communication” (like documentation), which only reduces the cost of a line, not the number of lines. Reducing the cost of lines is good, but will be overwhelmed by combinatorial explosion of new lines if you don’t work to remove them.

Removing a line of communication only happens if the communication isn’t necessary. The model here is to think of that part of the team as external. If I add AWS to my project, I expect a lot of productivity gains, but I don’t add in communication lines to every developer that built it. A lot of teams move to architectures like micro-services to reduce lines of communication, which is supposedly how AWS came into existence in the first place. That’s one way, but you can get there with clean API’s in libraries too. Whatever you may think of external library dependencies (I think of them as instant tech debt), they can make us more productive (just not for free). If you added developers to make a library for you, you would get the same benefit if they could stay as independent.

Once you have independent sub-teams, they can add developers because they are small. At Trello, when I was on the iOS team, I relied on the Trello backend API, but I didn’t need to communicate much with the developers that worked on it, follow their daily PR flow, or go to their meetings. As a principal engineer, I did read their RFC’s, but most of my team didn’t need to. When the backend team grew, my productivity wasn’t affected. Our team was small, so we doubled in size without causing the backend developers any trouble. Our lines of communication increased, but it was manageable.

Independence wasn’t only at the code level. Teams at Trello didn’t have a shared development process. Many teams did sprints, but they didn’t need to sync with each other. Teams that worked on the same deployable had to communicate more, but it was more hub and spoke rather than every possible pair. One way we did this was to have a role called a “feature lead” who was a focal point of communication. They would have a line to each developer on their project, but could help the rest of the team members stay independent from each other.

So, to add developers with less communication overhead, create small, independent teams. To the extent that there are dependencies between them, try to concentrate that in a few people, rather than spread the effect to everyone.

The Case for Adding Entry-Level Devs to Your Team

To be clear, by entry-level, I mean 0 years of experience, but with the skills that you would get from a bachelors in CS (or related) and some internships. Going by myself, when I graduated, I had built a compiler, a SQL-like database, a 3D modeling and animation application, image processing algorithms, a robot-arm controller, a theorem prover, etc. I had used version control, worked in the computer center, and had some tech-related summer jobs. This pales in comparison to what I’ve seen from modern CS graduates.

When I was hired at my first job, I fixed a lot of bugs to learn the codebase. My first big task was to reduce the memory footprint of our application by rewriting our windowing code (this was on DOS, so we simulated windows with ASCII Art). I worked on build scripts. I helped port our software to UNIX. I fixed a lot of core dumps. I worked on our printing code (yes, printing to paper). I could do all of this without understanding what Foreign Exchange Options were (yet). There’s a ton of work like this on most teams, and frankly, you are overpaying if this is what you have your senior devs doing.

That’s the main reason you need entry-level devs. There’s a lot of work that is only cost-justified if they do it. They can learn while paying off some technical debt, automate tests, and fix the quality-of-life bugs that make your app look unpolished. They can learn your domain by participating in code reviews.

The second reason is that all of this work is hindering your senior staff from growing. They shouldn’t be doing this work—they should be driving bigger outcomes (as I wrote on How Senior Software Developers Think). You are risking them leaving because they fear having 1-year of experience 5 times.

Finally, healthy teams have a diversity of experiences. An all-senior team may seem great, but they will have more groupthink than a team with some junior developers. It gives seniors a chance to mentor and will frankly make them code better (because it needs to be understood by less experienced team members). Having to explain things makes sure you understand them yourself. Documentation will be better, because you need it to be.

If you know how to retain them, entry-level developers grow with the company. Our CEO had started right out of school (where he was the first hire, I think). I eventually went on to lead the engineering team. At Atalasoft, we hired mostly entry-level, and they went on to build the products that were the basis of our acquisition. My last job, Trello, was co-founded by Joel Spolsky, who famously wrote about how to find great developers – TL;DR: get them at the entry-level. When I joined, a lot of the engineering team (that had built Trello to 7 million users by this point) had been hired out of college.

I understand that there’s risk, but learning how to recruit and evaluate entry-level developers is a core skill that your team should have.

Supernote Manta: Review at Four Weeks

I got a Supernote Manta about four weeks ago, and I wrote Supernote Manta First Impressions after using it for two days. Looking that post over, the only thing different is that I found out that you can use handwriting instead of typing in a lot of contexts by tapping the globe icon that shows up on the keyboard. This is marginally better than typing (which is very bad), so I still hope that it can get better in software updates. But, those impressions were about the visceral feel of the device, not how useful it is in practice.

After four weeks, I continue to be happy with Supernote as a replacement for paper journals. I have been using paper for my whole life, so I didn’t think this would be possible, and maybe it’s specific to me, but here are the reasons why I find it better than paper:

  1. My ideal journal has a lot of pages. In 2024, my journal was almost 400 pages. It has gotten too big to carry. On the Supernote, I don’t have to think about this at all. I created a custom journal that has a page for each day and a lot more.
  2. I like editing. I have come to rely on undo and cut/paste. I never had this with paper and didn’t consider this when moving to a tablet, but now I realize how important it is to me.
  3. It’s also great for reading. The Supernote with the Kindle app is as good as my Kindle device, which I don’t use any more. So, in addition to not lugging my paper journal, I can also not take the Kindle (which was always in my daily carry).
  4. It has all of my journals. I keep different kinds of journals. I have my daily, bullet-like journal, but I also have project specific ones and others (see Write While True Episode 21: Dedicated Journals). They are all slowly being migrated into the Supernote.

All of this would not matter at all if the writing on the device wasn’t comparable to paper. It is.

For me, the biggest downside (compared to paper) is that it is monochrome. I practice Two Color Journaling, where most writing is in black and important things are in red. I have been using other cues to highlight (symbols, boxes, the highlighter). It’s ok. I don’t think the new Remarkable (with color) would meet my other criteria, but it’s something to think about for the future. I guess I hope that color e-ink becomes ubiquitous and is available in a future Supernote.

The Entry-Level is the Applicant’s First Job

I spent some time today reading entry-level job descriptions on LinkedIn. There seems to be a widespread misconception that entry-level means “doesn’t have a lot of experience”, but entry-level means “no experience” — it’s right there in the name.

In addition to requiring a couple of years experience, these jobs also seem to require skills that would be very hard to obtain without a job. It’s shortsighted and very unlikely to result in good hires.

Imagine what this employer is thinking: There is a person with 2 years experience at a job where they got all of this great experience, and now they are going to move to your (excuse me) shitty job. They are not.

Let’s assume this person is great—I hate to tell you, but they are not looking at junior/entry-level jobs. Either their current employer is smart enough to know how to retain them (hint: with money), and so they will not be considering you or, if they are looking, they are looking to move up.

The person with 1-2 years experience that is fine with another entry-level job is doing this for a reason. In the best case scenario: they are in a bad job and need to get out—guess what, your job looks just as bad. My evidence for this is that you don’t know what “entry-level” means and are likely going to have unrealistic expectations and be another bad job. They know this. They missed the red flags before, but they see them now.

Posting entry-level jobs that are not entry level is a signal that your job sucks.

Why Even Triple the Number of Posts You Write

In Triple the number of blog posts you write and the follow-up to it, I gave some examples of how to triple the number of posts you write. This is the third post in that series, where I will tell you why I even think this is a good idea.

Again, I will turn to Art and Fear [affiliate link], because another lesson I learned from it is that the point of making art is because of the effect it has on the maker. Writing is how you become a writer, so doing it more will make you better, faster.

I prefer that reason to something like: the Google algorithm prefers it, or it’s easier to share on social media, or your AdSense revenue will go up if readers need to click around. There are no ads on this site, so I don’t care about CPM prices or page views. I would love for my SEO to be better or for more people to share my work, but the best way to do that is to just make a lot of good work.

I have no idea which posts will do better than others. I have written before that the highest traffic page from search is my UML Cheatsheet. The second highest had been my explanation of the tech that The Wizard of Oz used to make his ghostly head. Those two posts are over 10 years old. Lately, my review of the Supernote Manta has climbed to the top of that list. I would never have predicted that these would draw the most search traffic.

In Blog Posts, Randomness, and Optionality, I wrote that every post is a lottery ticket to some future benefit. I can’t predict what will happen to each one, but I know that having a lot is good.

Triple the number of blog posts you write: Follow-up

In yesterday’s post, I had some ideas for tripling the number of posts you write, but I forgot one source of posts: the follow-up.

I had mentioned that Art and Fear [affiliate link] had been the source of my advice to focus on ideas that have thousands of variations (not ideas for single posts). Another lesson from that book is that old (flawed) work is the inspiration for new work. I frequently read my posts hoping to find that it’s flawed in a way that inspires me to write more on the topic.

Now, this post might be a contrived example. I wish I could say that I planned it this way when I wrote the first post, but I’m not that clever. But I did read yesterday’s post and think: why did I not plan out three posts on how to triple my number of posts? And then I thought: what would I have planned? And this post is not what I would have planned, but it’s what came out of thinking about what more I had more to say on this topic.

The reason I am able to do this is that my posts are not meant to be my exhaustive view. I am following my advice to Lower the Bar to Practice, and that means I publish posts when they are good enough to publish, not the best they could be. I know that there’s always room to add more later.

Triple the number of blog posts you write

One of lessons I got from Art and Fear [affiliate link] was to not focus on ideas for a new piece of art, but instead to find ideas for Thousands of Variations and use that to produce A Life’s Work. I do that in the large with this blog, but you could also do it for each new post. If you have an idea for a post, try to think of two more that are closely related.

Sometimes, while writing, I realize that I need to explain something in an aside. Instead of doing that, I write that aside as a post first, which I can link to. The aside may not seem like enough, but I find that when I can give it its own space, I can expand on the idea. But I do it even if it seems short.

Another thing that happens in my first drafts, is that I discover in my first pass edit that a paragraph or two just doesn’t fit at all—it’s not an aside, I was just rambling. I don’t delete the text, I move it to my notes as the seed of a new idea. I discussed this in Write While True Episode 6: Editing First Drafts. If those paragraphs are developed enough, I’ll start a quick draft in my blog editor to look at later.

Finally, some posts are cohesive, but just too long. Those can usually be broken up into a few parts, which make it easier to digest. The individual posts are often easier to link to because they are focused. For example, I learned three lessons from Art and Fear, but by breaking out the “Thousands of Variations” into its own podcast, I got three podcasts out of those lessons, but also, this one is easier to refer to.

Write While True Episode 45: Gather Your Work

Podcast: Play in new window | Download

But even with all of that new writing, a lot of the ideas and content are drawn from my blog. That’s what I want to talk about today — How I started this project by reviewing and gathering my work.

My first step, at the end of 2023, when I decided that I wanted to write a book, was to immerse myself in my own writing, so I just read my blog. I just read all of the posts.

Transcript

The Lorraine Hotel

I’ve been to Memphis twice, which means I’ve been to the National Civil Rights Museum at The Lorraine Hotel twice. The first time was in the early 90’s and the second time was in 2022. My memory of the first time was that it was just the Lorraine Hotel and walking through it was a fairly short, but powerful experience. After seeing a retrospective of MLK’s life and the 60’s era civil rights movement, I watched a video of his “Mountaintop” speech where he seemed to predict his own death, and then walked to his room, and then to the exit. Everything was quiet. We were within a few feet from where he was shot. I just stood there and let all of it overwhelm me as it should.

A photo of the Lorraine Hotel. There is a flower wreath at the spot of MLK's death. The hotel has been preserved to what it looked like then with two cars from the time parked outside.

Why ChatGPT Works Better for Newbies than StackOverflow

On StackOverflow, it’s common for newbie questions to get downvoted, closed, and draw comments making fun of the questioner. To be fair, many of these questions are not good and show that the asker didn’t follow the guidelines. Even so, StackOverflow is often hostile to new programmers. To be honest, I’m surprised that ChatGPT didn’t somehow learn this bad behavior.

ChatGPT answers are sometimes totally wrong, and they will be even more wrong for the way newbies ask questions. If they weren’t, StackOverflow wouldn’t have had to ban answers generated from chatbots. But, I still think ChatGPT a better experience because it’s fast and synchronous. This allows it to be iterative. Of course, this doesn’t help if the suggested code can’t be used.

If I were StackOverflow, I might consider how LLMs could be used to help newbies ask a better question that gets answered by humans if the LLM can’t answer. Let the user iterate privately, and then have the LLM propose a question based on a system prompt that understands StackOverflow guidelines. Normally, I’d expect the LLM to be able to answer at this point, but I just ran into a problem yesterday where it kept hallucinating an API that was slightly wrong. This kind of thing happens often in ChatGPT for me. In a lot of cases, I could guess the real API or search for it in the docs, but a newer programmer might not be able to do that.