Author Archives: Lou Franco

Programming is Disambiguating

If you follow a programming tutorial, at the end you will have some working code. You will hopefully have some idea of how it works.

But, you haven’t learned how to make this code. Programming is different from woodworking or playing a guitar in this way, because they require training your hands. Watching and repeating what you see will work to help you learn and improve.

In programming, it’s good to type fast, but most of what is happening when you make new code is in your head, and tutorials don’t train that part.

This is why I think Programming Tutorials Should be Vaguer. Programming is taking a nebulous problem and breaking it down, understanding it, trying to find building blocks, and then building up something that solves the problem.

The final form is concrete, but it is made by going through multiple phases where you took unclear ideas and made them clearer.

We need tutorials that ask more questions and provide fewer answers.

Podcasts for Companion Learning

One of the advantages of podcasts is that they are audio-only, so you can listen to them while you do other things. I listen while doing chores, running, cooking, and driving. I mentioned in Soundtracks for Books that it’s hard to listen to something while you are doing effortful thinking.

But, just like a book soundtrack, you can pay attention to audio if the thing you are doing is really the same thing—something integrated with it.

I haven’t seen this much, but I think a big area for podcasts could be in guiding “learning by doing” tasks.

There are lots of video and text tutorials for learning programming. The issue is that you can be tempted to consume them without really doing the tasks yourself. And since you have to look at the book/video/blog etc, it’s hard to also be looking at your editor.

This kind of podcast could not just be played in your regular playlists though—you need to be at your computer ready to listen. It could guide you in a vague way, so that you have to think in order to do the tasks, not just listen while you exercise.

I’m not sure that a programming guide podcast is a good fit for very new learners, who still need a lot of help with the syntax. It would be better for learners who can write lines of code syntactically correct from a short-hand description.

Like I said in Vague Tutorials Would Help with Coding Interviews, I think getting good at taking spoken directions would help in coding interviews.

Kite: First Impressions

I wrote in Robotic Pair Programmers:

If search engines ever get eclipsed, I think it will be by something in the environment that just brings things to your attention when you need them. I want this most when I code, like a pair programmer that just tells me stuff I need to know at exactly the right time.

Kite, a code editing plugin, seems to be trying to go down this route. They have “AI powered code completions” for 16 languages in 16 code editors. Unfortunately, they don’t support Swift in Xcode yet. But, they do support Python, HTML, CSS, TypeScript, and JavaScript in VSCode, Sublime, and all of the JetBrains editors, so I could use it to work on App-o-Mat, which is a Django-based site.

In addition to code-completion, Kite also offers Copilot, which is a documentation pane that is synced to your cursor. Xcode already does this—the issue is that a lot of Apple’s documentation isn’t very complete. Kite only supports this for Python right now, but one addition to the standard docs is they link out to open-source projects that use the type or method you are editing.

Unfortunately, Kite doesn’t work on Apple Silicon, yet. It uses TensorFlow, which uses a particular instruction set that isn’t supported by Rosetta. Apple seems to be working on getting TensorFlow ported to M1.

So, I’ll have to wait to try it out. Very promising though.

Proposal Tip: Offer Choices

Most of my consulting proposals have options in them. I generally think that customers like having a choice in how to proceed, and it gives me a chance to express different ways I could help.

It’s hard not to have a preference for what they might pick. For example, you might want them to pick the most expensive option. I don’t always want that—sometimes an option is expensive because I don’t want to do it.

But, I find it best if I am neutral to their choice. I don’t want to be disappointed if my preferred option isn’t chosen.

In contrast, I want the customer to have a clear best choice. I don’t want them agonizing over the options, so they are usually pretty different. I might not know exactly which one they want, but it won’t be a close call.

For example, in an app proposal, one option might be to build the app. I don’t offer different ways I could do that, but I might offer to only be a project manager for an offshore team instead. Two very different options.

Each option is acceptable to me, but I think the customer would find choosing one easy.

NERD Summit 2021

The NERD Summit is going to be virtual again this year. It’s the weekend of March 19-21. There are tons of great sessions for beginners, so if you want to get into programming, you should take a look.

I spoke at the conference in 2017 about how to practice iOS development. As part of the talk, I open-sourced an app that could be used for conferences, which I forked into the conference app for NERD Summit. You can download it here (it’s been updated for 2021).

The source code for the conference app is on GitHub. Feel free to fork it for your conference. It’s easy to adapt — it uses a couple of google sheets as a data-source, so if you update the URLs to sheets in your account (make them publicly readable), you can show your conference events instead.

A Cover Letter is an Argument

A few days ago I wrote that your resumé should make no sense, where I explained that you should customize your resumé so that it is tailored to the receiver to such a degree that sending it to anyone else would make no sense.

A cover letter is similarly customized, but I think that’s more obvious. Never use a generic cover letter. If the application is cold, you need all the help you can get. If it’s not, for example, if you are being referred, then you really need to mention that.

The cover letter is a response to the job description. It is a point-by-point argument for why you are best person for the job as it was described. It is a guide for navigating the resumé. It is a writing sample. Every job description asks us to have excellent communication skills. Your cover letter is the way you prove this.

Before you even start to write it, you need to dissect the job description and pull out the most important asks where you have an excellent response. If you don’t have an excellent response, this might not be the job to apply for.

You will also have one or two things about you that are so great, that you need to get them in the letter. This could be a side-project or open-source contribution, a talk you gave at a conference, some technical achievement at work.

Finally, you should research the company enough to try to find other things that would make you a good fit. Read the company blog or twitter. Get a sense of who they are. If the company is small, you might be able to find team members or the hiring manager of the job they are looking to fill.

With all of this raw material, write a letter that makes it clear that

You are specifically trying to get this job, not any job
You are willing to put in work to get it
You have the required skills of the job
You have excellent communication skills

From experience I can tell you that getting one like this is rare. When I am the one filtering the pile, I will always call anyone that does this and give them a chance.

I got my last two jobs with cold applications and extremely custom letters. Of course, the letter just gets you the interview, but you are going to do a similar amount of preparation for those as well.

February 2021 Blog Review

This month I talked about how The Practice helped me understand what I am trying to do by blogging and motivated me to blog every day. I shared some tips to how I am doing that.

Start the day by writing morning pages, then write a shitty first draft.
Keep a long list of topics.
Bank blog posts.
Edit by using the editing sweep method.
Write a lot of posts to become a better writer.
Generate topics with these tips. For example: Mining your tweets or writing while reading.
Use media depravation to make space in your brain for your own ideas.

I offered some tips for technical job seekers.

Write a job statement
Build your network by being useful to people
Don’t be afraid of rejection.
Make your resumé specific to the job.
Prepare for interviews like they were a performance.

Your Resumé Should Make no Sense

If you sending out resumés and getting auto-rejected or never even contacted, let me help you understand why.

Yesterday, I wrote about writing a Job Statement, which is a very specific description of the job you want. You can think of it as the employee equivalent of an employer’s job description.

You are now looking for something very specific. And when you find one to apply to, you are also a very specific person.

So, why is your resumé generic? If you could send this same resumé to lots of different software developer jobs, then it’s going to get filtered out for a lot of them.

Consider the receiver. If this is a well-known company who will get a lot of applicants, they may get a hundred applicants to every position. I worked for small companies in small job markets and could get that sometimes (especially when we targeted new grads at the local colleges).

With such a pile, the reader has no choice but to skim each quickly. Imagine that they will read the very first lines and then skim for a few pieces of key information. If you pass that, they might give it a more careful read. It is also possible that they are using crappy software to score the resumé ahead of time.

Why will your application get chosen?

Here’s one way. Your resumé should be so specifically meant for that job that it would make no sense to send it to anyone else.

Doing this takes a little longer than just spamming job sites with your generic resumé, but the hit rate is worth it. And it’s really not that bad. You are going to start from a long generic resumé and edit it to be more focussed. I personally maintain a few styles because I have more than one domain I am willing to work in (and they are different enough to warrant this).

Read the job description very carefully and figure out the one or two most important things they are looking for. Take note of the words they use, especially jargon or technical terms, because you will use them as well.

The very first real sentence of the resumé, below your contact info, should be a concise argument for why you should be hired for this specific job hitting those two most important points.

Next, should be a concise summary of your technical qualifications, edited to be specific to this job. Maybe label this section “Relevant Skills” if you are afraid you are editing it down too much.

In every job you list, make sure the reader can skim and see the tech stack you used there (bold it). Use the job description as a guide to what you write about the job.

The description of your current job should be very specifically tailored for this receiver, and you can do this to a lesser extent as you go through the resumé (but it won’t hurt to do it completely).

If you need help, please get in touch.

Your cover letter is going to be even more customized. I’ll cover that soon.

Note: If you think your resumé will be auto-scored, the standard recommendation is to make sure your resumé has the keywords they are looking for. Since you are tailoring the it to the job description, you should be fine.

Job Seeking Tip: Build a Job Statement

If you are looking for a job, write a very specific description of what you are looking for. Do this even if you think you’d take any job. Looking for any job doesn’t help you focus your actions, but when you get specific, it’s easier to think of things to do that would help find it.

Why?

There are a lot of different jobs and good ones get lots of applicants. The goal is to make you into the perfect applicant for the job you want. This way, you’ll spend less time applying and preparing, and when you apply, you’ll be sure to stand out.

If you don’t do this, you may find yourself spending a lot of time spinning wheels and getting nowhere. You won’t have any good way to evaluate job listings, or even start searching for them.

You will probably apply to way more jobs than you should, and then, you won’t be giving the proper amount of attention to any of them. In frustration, you might just take the first job that comes along.

So, write a job statement

Break down all the aspects of a job and try to figure out what’s important to you.

Answer these questions:

Where is the job located? Is it near home? If so, what is the maximum distance? Any particular neighborhood or town? If you are willing to move, what kind of place? In your state or country? To a city, a small town? Does the place need to be near anything (downtown, a highway exit, a train line, etc). Or does it not matter because you want to work remotely.
How big is company? Is it just a few people? A big public company with international offices? Or do you just care about the team size? If so, how big is it?
What domain? Is the software for internal of external users? Is it horizontal or for a specific vertical (like healthcare or finance)? If vertical, which one? Who are the customers?
What technologies? Any particular language? Web? Mobile? Do you care about whether you use OO or functional style?
What is your role at the company or on the team? Team member, lead architect, team lead?
How much do you want to make? Can a part of the pay be equity? If so, how much? What kind of benefits and vacation?
What kind of company culture? Casual? Business casual? Formal? Flexible hours?
How much travel do you want to do? None, weekly, occasional? For what reasons? Customer visits? Conferences? Working in different offices?
Contractor or employee? Part-time or full-time?
Do you care about the office space?
How about the team’s abilities?
What about their contributions to open-source?

The next step is to prioritize your answers. Once you do that, you can use this statement in so many ways.

To form search queries on job sites
To find Linked-in connections to reach out to
To customize your resume
To drive your self-learning for gaps you might have in qualifying for the job you are looking for
To make a list of companies that match your criteria.

Another effect that isn’t so obvious is that it helps you recognize serendipitous leads. When you are tuning into something specific you start to notice it everywhere. If you mention your search to other people, they will think of you when they see it. The randomness of the world starts to work in your favor.

Please reach out to me if you need help with this (message me on LinkedIn). I can help a lot better if you are specific.

Writing vs. Thinking About Writing

In my review of The Practice, I said that I was posting every day to focus myself on writing something worth posting every day. Shipping makes me think about a reader more than journaling would.

But, I am definitely not worrying too much about quality because I believe that that will come with time.

This story from Art & Fear [amazon affiliate link] is often cited to illustrate the power of quantity. I heard it first from Coding Horror in 2008, but here’s the earliest reference I could find:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

[…] Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

When I think back to how I learned programming, I remember that I did it nearly every day and produced a lot of code. Most of it was unshippable, but I learned from making it and eventually learned to ship it too.

I believe in combining identities to build a new skill from a developed one, so applying my code writing attitude to writing text will help me keep going. I have seen the power of quantity work before.

I have also seen the effect of “theorizing about writing”. I have been trying to write more for years. I started this blog in 2003, and right now, just two months into 2021, I have more posts than any other single year.

Thinking about writing produced very little. Please, don’t wait eighteen years to learn this lesson.