Lesson 1
Realities of ESL
In our experience with Lambton students and speaking with many companies that have also hosted Lambton co-ops, most people find the biggest challenge in the placement is communication. This is just the reality of English being a second language for Lambton students, along with the inexperience and lack of confidence of working in a development team.
This challenge can be overcome by using the various project management and communication tools your team has to communicate passively, while you develop more confidence in the active communication required of a developer. It is very important that you make sure everything is understood both ways:
When someone is explaining something to you
When you are communicating something to a teammate or the team
Know that there will be times where both of these things happen, and you have to take the responsibility to make sure everything is understood. It is better to ask for help or more explanation than to spend time producing work that may be wrong. Take the time at the start of a task to ask for clarity, the time spent explaining at the start will always be made up for in eliminating working on the wrong things or the wrong way.
We can not emphasize this enough, do not be afraid to ask for help. Although you will be expected to be responsible for your own area as a developer (more below), you are also not expected to know everything about the code you are working on or the languages it is written in, especially in the beginning. You are also not expected to get anything perfect the first time you do it. This is coding, nothing will ever be perfect. It is more important to focus on getting things done, asking for help where needed, then fixing things as you go. We will talk more about this lean/agile approach to development more below, but the general rule that we have our team go by is:
For our team this means developers should be working on the things they need to and if they run into an issue that they can not solve, not getting stuck on it for too long. So, if a developer gets stuck on an issue for a certain amount of time, they have to stop working on it and ask on stack overflow or one of the more senior team. If the issue persists, the developer is supposed to bring it up in the next team meeting to have the group help work it through.
Each team will have different rules of how to escalate troubleshooting, it is important to understand what they are and how/when to ask for help appropriately. As a developer you keep a balance between being responsible for getting the things assigned to you done, with asking for support at the right times to prevent too much wasted time. In today’sLeandevelopment environments (which we will talk about more below), getting things done (shipped) is more important than getting them perfect.
Responsibilities as a developer
You have both direct and indirect responsibilities as a developer, and each company and team is different in how they divide and assign technical responsibilities. As a developer, there is a certain amount of your job where you will be expected to be self-directed in accomplishing what has been assigned to you. For whatever tasks or features are assigned to you, you will be expected to directly be responsible to:
Get the task done in the given timeline
Speak about the task in team meetings
Ask for whatever resources are needed to get the task done (like designs)
Communicate about the task in project management tools
In completing these tasks, there are also the indirect ways you will responsible to:
Setting up your computer/environment
Troubleshoot on your own
Ask for help when needed
Get to know your code base/development stack
Agile/Lean
Before we talk too much about the tools and documents used for communicating as a technical team, it is important to have a basic understanding of the process and approach of most technology companies in modern development.
Lean Startup Methodology
This approach to development started in the Valley with startups, but is now being used throughout technical development, even by governments these days. It operates on the principle that it is more important to get software products out to users and have them start to use it and give feedback, than it is to get the product right the first time. The basic principle ofLean Methodologyis to come up with ideas and then build them (1), measure how people interact with what you have built (2), learn from the data on that usage (3) to come up with new ideas to build, then repeat (4):
The goal of this method is not to build perfect technology, but rather to get this feedback loop happening as fast as possible so that better technology evolves through these iterations and user feedback (technical velocity). The first version of an app or feature is called the minimum viable product (MVP), which is essentially the least amount of things (code, buttons, screens, etc) needed to accomplish a given use case. So, the goal is to get an MVP out and start iterating on it to continuously improve it.
This dramatically affects the job of developers as it both speeds up the development cycle and tries to break down feature development into smaller stages. This also means that sometimes things that have been worked on and produced end up getting thrown out, or priorities dramatically shifting from week to week based on what the users dictate. As a developer, you have to expect that there will be plenty of changes and some of your work may even never be used, but that is part of the process and not necessarily to be taken personally.
Design by Iteration
Another aspect of the Lean method is that some degree of product design always happens by this iteration. Some teams may have a designer build out high fidelity mockups and even do user testing on prototypes before features are built, while others may just draw it on a whiteboard first then make changes to the designs once people can interact with the UI/UX. Either way, once the feature is coded it will inevitably change based on user feedback, so expect some degree of the feature design to be through this iterative process.
Agile Development
An extension of the Lean approach is a focus on agile development over the more traditional waterfall approaches. We will not get into all of the mechanics ofAgile, as every team executes these principles in different ways, but the basic components are:
Sprint cycles - shorter timeframes around production usually 1-4 weeks. This means that things started in this cycle will be completed by then end of the time period and ready for deployment. A sprint usually follows:
Scrum to lay out the sprint goals
Design and scoping of the feature
Build features and deploy to a testing environment
Test and QA feature
Debug
Repeat 4 & 5 until bug free
Deploy to Master branch with other features from this sprint
Publish new version with all features from this sprint into production
Scrums - scrums are the type of meeting that usually correspond with Agile development and describe the technical team getting together to plan a sprint. This planning usually follows:
laying out all of the possible features that could be built
selecting the most important ones (from user feedback)
Scoring the possible features based on time/effort needed for development
choosing/assigning features to teammates
Measuring the overall score and goal velocity for the team
Releases - with Agile, releases are coordinated throughout the team and code is merged at the various stages of production. This ensures that features can be tested separately and as a whole as they go through the production cycle and that even though features are produced at a high velocity, things work well before being released to the public. Using version control, a typical release goes through:
Being built locally on the developers device
Getting pushed into the staging or development environment for testing
Being merged to the production code base when it passes testing
Being published to production with the other features.
Active Communication
This type of communication is all of the ways you will have to speak or write about your job or the tasks assigned to you. Again, every team is different, but most teams will use some or all of the following for communication, along with what you need to be prepared for:
Email - ask or figure out early on what type of things should be communicated by email. Most modern teams actually email very little given the other tools they have (and because of Slack), but, especially given that English is not necessarily your first language, sometimes things can be more clearly communicated when written down.
Slack - used by most technical teams (or else Microsoft Teams) and eliminates the need for any emails. This can be used for direct communication with teammates and channels along with @user can be used for conversations where more people need to be involved. Like email, writing out your communication on Slack can help if you are concerned about language challenges. It is also useful as a way of communicating something to teammates without interrupting their workflow, and they can answer when they are finished whatever it is they are working on.
Team meetings - find out the frequency and purpose of your team meeting schedule. You should be able to get the agenda of meetings ahead of time to know what to expect as well (or at least be included for the invite). Most important is to understand if you are responsible for anything in the meeting and be prepared to speak about this topic.
Standups - many teams will have a daily standup or a couple times per week, especially if they are Agile based. These meetings are just a quick chance to discuss what you are working on for the day and a quick update from the last standup, so be prepared to share this information.
Demos - many teams also have demo meetings at the end of the sprint for the developers to show what they have built. Be prepared to show what you have built, speak about the feature and answer any questions to challenges you had.
We also spoke with a number of other companies who have worked with Lambton co-op students and heard many of the same things from them about communication. One of the challenges in addition to English being a second language, is that Canadians are an overly polite people, who also expect that same level of politeness (or can find very direct speaking to be rude). This is a little more than just ‘saying please and thank you’ (though those are both good habits to be in), but applies in how you communicate certain things. Some of the other specific feedback we heard about communication and the ways that you should handle them are:
Email etiquette - email messages that are much too direct or unfriendly. Unless it is an ongoing email conversation, make sure to start each email by addressing the person you are emailing (Hi <Name>) and end each with a polite closing message (ie Thank you, Take care, Regards, etc).
Asking for time off - these messages being late in delivery or too direct. Everyone needs some time off for different things, it is important you ask for it ahead of time and in the right way. Ask your supervisor if you can take time off as far ahead of you needing that time as possible. Do not tell your supervisor you need time off when you are already taking it. This does happen and should not: ‘Hi, I need to leave work today at 3pm for a doctor’s appointment’ said at 3pm to the supervisor.
Sick or late - these messages being delivered late, in a too direct fashion (telling, not asking) or without options. Stuff happens, and that is ok, but you need to communicate these things as early as you can. If you realize you are going to be late, you should let your supervisor know as soon as you realize it, do not just show up late then explain why afterwards (especially for meetings). If you are feeling sick, you should let your supervisor know when you are feeling that way and ask for options (some teams prefer people work from home than get others sick). If you wake up feeling sick, let your supervisor know right away and do not wait until you are already late for work to let them know.
Addressing supervisors - being much too formal in speaking with supervisors. Ask your supervisor what name or title they prefer to go by and use that. Most people will not choose to go by Sir or Maam, especially once you start working together.
‘Yeah sure’ - using this as a default saying no matter what. Several different supervisors told us that their students respond with ‘Yeah sure’ when asked many things, especially about their responsibilities, even when the answer may be ‘no’. Do not just agree with a supervisor when they ask you something unless you understand clearly what they are asking. On our team, when a developer answers ‘Yeah sure’ we ask them if that means Yes or No.
Passive Communication
There are also different ways to communicate passively or indirectly with the different tools used by teams. In these circumstances, using the tool or including more of the team in a conversation helps communicate other important things to teammates:
Emails/channels - whether in a group email or in a Slack channel, if there is something to be said between you and another teammate that may be important for others, make sure to include them in the email/channel. That way you do not have to repeat the communication with each individual.
Sprint Boards - whichever project management tools your team uses, there should be some form of sprint or feature board that manages progress. Keeping those cards updated with details as well as moving them through different stages of development help communicating what you are doing without having to report it. This is also a good place to make comments or @user teammates if you need something in order to move your own work along.
Bug Tickets - similar to the Sprint Board, wherever the team communicates bug/issue tickets is another place to put lots of information or updates in order to communicate progress or needs to teammates without the need for direct communication.
Specs
The final element of team technical communication to review is the product spec or design documentation. Each team will have a different process they follow to help scope out and communicate features, ranging from just everything on a Sprint Board to formalized specification (spec) documents. Some of the common elements in these documents or boards are:
User Stories - A walk through of what the user needs and how they would use the given feature/app. This stage focuses on the ‘what’ users will do and are written more from the customer service side than the technical side. These are high level stories about the behaviours a user will take.
Requirements - this stage is more technical and focuses on the ‘how’ to deliver the user story. It gets into the technical details of what is needed to deliver a given feature, laying out the different views, screens, elements and calls needed to deliver the function.
API/Data Model - this stage focuses on what is needed from the back end, calls and data, in order to meet the requirements being built on the front end.
Designs - the last stage is to get designs or prototypes of the different screens with all of the requirements laid out and styled how they should look in the working feature.
You can see a very basic spec of the project will we work through during this course that is shared in the ‘documents’ channel on Slack.
Conclusion
This lesson is important to work through as you get started in a new job/placement and learn about the processes and systems that are in place. Effective communication and usage of tools can save a lot of time in development and avoid a lot of unnecessary meetings. Make sure you understand the processes your team follows and these takeaways about communication:
It is your job to communicate AND understand clearly
Own your responsibilities
Ask for help
Figure out team processes
Be prepared, know your tools
Focus on velocity
Last updated
