Richard Gould

CTO, Software Developer, Language Learner

Valued Leadership Qualities

| Comments

Here are the qualities and characteristics that try to demonstrate as a leader. I consider this a work in progress, and will expand/edit it as I grow. These are in no particular order.

Communication: A leader should foster communication amongst the team, as well as between other teams. It’s better to over-communicate rather than under-communicate. Communication should ideally be clear and direct.

Patience: Impatience adds stress and anxiety to team members, who otherwise do their best work when relaxed and comfortable. Team members should feel confident in admitting mistakes (after all, everyone makes them), and should not be punished for them.

Listening: One of the most important skills, in my opinion. A team member should feel comfortable bringing any problem to a leader. If one does not listen, that level of comfort is difficult to establish. A leader should not interrupt others when they speak, and should seek to understand what the team member is trying to communicate, rather than waiting for their turn to speak.

Humility: I believe everyone can learn something from anyone else, regardless of their age, experience, or background. Keep an open mind, and be open to new surprises. Leaders are not better than others.

Appreciation: A leader should show appreciation to all around them, but especially their team members. A lack of appreciation makes others feel unimportant, decreasing their morale and motivation.

Encouragement: One should encourage, not disparage. Reward the good behaviour that they observe by showing appreciation. Encouragement helps team members go further, and increases motivation.

Vision: She should know where the team wants to go, and be able to help the team get there (even if they themselves don’t know how). This includes both short term and long term goals. They should also show how each team member’s work contributes to the team’s goals.

Focus: A leader should help the team focus their efforts, steering them in the right direction so that they can strive towards their vision. They should set goals and help the team focus on achieving them.

Mentorship: They should help those around him grow, challenging them to expand and strengthen their skills, both professionally and personally. Identify weaknesses and encourage team members to address them.

Interest: Take a genuine interest in team members, building rapport with them and supporting them. There should also be a genuine interest in the problem domain, and a leader should seek to grow their expertise with it.

Problem Solving: A leader should be able to help solve the team’s problems, whether those problems are within the team (ie. conflicts) or without (ie. technological or organizational blockers). Solving these problems lets the team focus on achieving their vision, without being distracted by other issues. A leader can help identify these problems, and also propose solutions and drive their resolution. These problems can be anything: technical, organizational, environmental, and personal.

Collaboration: Getting the team working together is more effective than issuing orders to team members. People feel powerless when commanded to do something. Collaboration gives the power to the team, regardless of seniority or title. A leader should do what they can to encourage such an atmosphere. When a problem arises, the focus to solve it is on the problem itself, not to lay blame on those involved.

Tolerance: A leader should foster an environment of tolerance, allowing team members to be themselves in an environment free of prejudice and oppression. This means immediately tackling issues such as (but not limited to) sexism, homophobia, racism, bullying, or antagonism.

Feedback: A leader is able to give feedback in a constructive and useful way, helping team members grow, rather than criticizing them and making them feel resentful.

See also my principles for software development.

Last updated 2021-02-09

Improving Your Speaking and Listening Skills

| Comments

A colleague wrote:

Hello! I want to ask you to share your experience or ideas about what is the better way to improve the English level. Of course, the question is not simple how it seems because I have not bad level (according to a test it closer to advance) and I try to use all general advice like use English sources for getting information (for my work and other aspects of my life), watch videos in English etc., but I still feel not comfortable in a speaking part and sometimes with understanding (some accents are easy to understand some harder). How did you manage similar problems? Thanks!

I believe the best way to improve your speaking is to, well, speak. The more you can speak, the faster you will improve. It can help to figure out what specific problems are being encountered. Others having problems understanding what you’re saying? Improve your pronunciation. Can’t recall the word you want to use in the middle of a sentence? Use Spaced Repetition Software (SRS) to boost your recall rates. Don’t know the word to use in the sentence? Increase your vocabulary size.

To speak more, try to incorporate speaking into your life more. If you can speak your target language with your friends or family, try to do so as much as you can. If you’re watching TV, you can repeat after hearing something (“shadowing”). You can also talk to yourself, which is maybe strange, but can be very effective. There’s an article over at Universe of Memory that goes into the details of talking to oneself. But speaking without feedback risks ingraining mistakes. To that end, I recommend hiring a native speaker who can give you feedback. They don’t need to be a trained teacher (those can be very expensive) - just a native speaker who can tell you when you’re saying something wrong.

I’ve had very good luck finding native speakers on Italki - you can find a native speaker there under “community tutors”. You can also find a language exchange partner, but I don’t recommend them. If you’re doing an exchange, you’re spending time and effort on your own language, when you could be spending that time and effort learning your target language. It’s also a significant amount of effort to find a suitable partner in the first place. Go with a community tutor if you have the financial means.

To improve your pronunciation, I recommend learning the IPA of your target language. Once you identify the words that you have trouble pronouncing, you can use the IPA to identify the specific sounds that are difficult for you, then intentionally practice them. Note that unless you’ve intentionally trained your ear to hear these new sounds, it’s unlikely that you’re hearing (and thus pronouncing) them correctly. As an example, see Perception of English /r/ and /l/ by Japanese speakers. The Speechling app can also help with this. You record yourself speaking sentences aloud, which are then reviewed by a native speaker who points out what is being said incorrectly.

To increase your vocabulary size, I recommend actively engaging with new words, or with words that you find yourself forgetting. To active engage, you can create sentences (written, typed or spoken) using these words. You can type them into your SRS application to decrease the chance that you will forget them.

To get used to different accents and speakers, listen to media from many different sources. YouTube is a fantastic resource for this. Listen actively, and try to pick out words. Take note of new words you don’t know and try to use them. I also recommend the article Listening comprehension in a foreign language - 12 ways to improve it.

To improve the recall of your vocabulary, I recommend using Spaced Repetition Software, in particular Anki. The vocabulary you learn will be periodically shown to you based on how well you know it. This helps slow down memory decay (see Ebbinghaus’s Forgetting Curve and the Spacing Effect). It can also be useful in identifying vocabulary that you need to pay more attention to, for example a word that you keep getting incorrect can be used in more sentences, help to boost the recall rate.

Disclaimer: I am no expert on language learning. I have some background knowledge, have read a bunch about it, but they were mostly secondary sources. I have tried many things and have failed more times than I have succeeded. Take my advice with a grain of salt. I highly recommend Universe of Memory as Bartosz actually cites his sources, so you can question his recommendations by delving into the source material.

My Principles for Software Development

| Comments

Here are some of the principles by which I try to develop software. This isn’t a hard-and-fast list, but rather a set of guidelines that I use. I don’t follow all of them every day, but I try to follow them as much as I can. This list is under constant review, extending and changing as I grow as a developer.

  • Don’t leave work unfinished - Work that is started but not finished is a liability. At best, it means a feature isn’t in production sooner than it could be (representing wasted opportunity). At worst, the feature will suffer from software rot, and may require substantial rewriting if left long enough.

  • Work on only one thing at a time - Mental context switching is expensive. Focus as much as possible until that item is done.

  • Teamwork - The team as a whole is more important than the individual. This means that you should write maintainable code, ask for help when you get stuck, and help out your colleagues when they need it.

  • Review pull requests thoroughly and in a timely manner - as part of teamwork and leaving work unfinished, review your colleagues’ work quickly. If they write a PR and it sits for a week, that is means it takes one week longer for that feature to make it into production.

  • Fix bugs first - Bugs should be fixed before anything else. They are easier to fix when fresh, and existing bugs represent potential bad experience for enduser. See the Pragmatic Programmers’ broken window theory.

  • Be aware of errors - Whenever an error or problem occurs, we must be notified of it. Otherwise, only users will experience it, and not all users report errors. Also if a bug is fixed before a user first notices, the bug doesn’t exist from their perspective. An app slowing down to unusable speeds is considered a bug.

  • Don’t live with pain - When something is frustrating, take the time to fix the problem for everyone. Automate common tasks. This makes life easier, and makes the software easier to work with. It’s not always possible given time contraints, but it’s worth it. This is how big things such as Rails or Meteor get built.

  • Produce high quality code - Take the time to do things correctly. Quality is worth it.

  • Be pragmatic (but balance ideals) - Striving for ideals is fantastic, but shipping usable code is the most important.

  • Don’t let email/requests go unanswered - Others have taken the time to ask something of you. Be courteous, and don’t make them wait.

  • Provide test coverage - Do this where possible. The value it provides is tremendous. Try to consider a feature to be complete when it has test coverage.

  • Keep learning - Always be trying to learn new things. This includes new ways to use existing tools, or new tools altogether. Tools range from programming languages, frameworks, paradigms, editors, to soft skills such as empathy and listening skills.

  • Blame problems not people - Don’t forget that code is written by humans, with real feelings. Focus on the problem itself; blaming the author is counterproductive.

  • Encourage, don’t discourage - Help others improve their code. Don’t put them down because they wrote code that you (subjectively) could be better. Yours could also always be better.

  • Be humble - Realise that you can learn from everyone out there, including those are just learning to write code, and even from those who don’t write code at all.

A good chunk of these have been taken from OK GROW!’s development process guide, which I’ve contributed to a bit.

A lot of these may seem like common sense, and I hope that they do. That’s a sign that you’ve got solid guidelines in place. But I’ve had some encounters with people who haven’t given such things any consideration, just like there are companies out there that still don’t use source code control.

What sort of guidelines do you use in your development process? Email me at rgould@u2622.ca or leave a comment below. I’d love to hear them!