☢ Thoughts on software development, with an odd jaunt into language learning

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!

5 Steps to Understanding Meteor Better by Improving Your JavaScript

| Comments

I don’t believe you need to be a JavaScript expert before diving into Meteor, but I highly recommend taking the time to learn advanced topics first. By levelling up your JavaScript, you will understand the concepts faster, and will feel less frustrated and confused. Even if you don’t stick with Meteor or do Meteor full time, the skills these books will teach you will help you in all aspects of development.

I recommend starting by watching a series of Douglas Crockford’s lectures on JavaScript, and then following it with Reginald Braithwaite’s Javascript Allongé.

  1. Watch Crockford’s The JavaScript Programming Language. Watch it even if you already have built some applications with JS already. It goes into the fundamentals in-depth, and will help cement the basics in your mind, which is essential when learning advanced topics.
  2. Watch Crockford’s Theory of the DOM. Watch it even if you think you know the DOM well. Again, establishing fundamentals makes learning advanced topics easier.
  3. Watch Crockford’s Advanced JavaScript. It covers some advanced topics sometimes unique to JavaScript, and common advanced patterns. If you’ve ever tried reading a JavaScript library and couldn’t even begin to comphrehend it, this lecture will help clear things up.
  4. Watch Crockford’s JavaScript: The Good Parts. It will help you pick out the best parts of the language to use, and the parts that you need to actively avoid.
  5. Read Reginald Braithwaite’s JavaScript Allongé. Reginald (aka ragnwald) covers advanced functional topics, and this will permanently change how you write your JavaScript, enabling you to write resuable code faster and with much higher confidence.

I recommend doing the above in that order. Allongé is more advanced and builds off of topics covered by Crockford. Each step will help bring your JavaScript game to the next level, with Crockford’s lessons establishing solid fundamentals, and Allongé teaching (in a very effective manner) the more advanced usages of functional programming with JS.

Note that I did all of the above (and worked through the exercises in Allongé) before I even touched Meteor, and for the most part, the only Meteor help I’ve needed has been the official Meteor docs. Having such a solid foundation of knowledge let me pick up Meteor with lightning speed, and all of those skills will stay with me when it comes time to learn another framework.

If you have trouble following Crockford’s lectures, then I recommend reading his print edition of JavaScript: The Good Parts instead. While you’re reading it, really work through the examples to make sure you’re understanding it as you go along.

Have you ever felt that your JavaScript skills were inadequate? Have you ever looked inside one of the libraries you use (jQuery perhaps?) and felt as though you didn’t understand JavaScript at all? I want to hear about it. Email me with your story (write as much or as little as you’d like).