Stand up

On a recent project, we hit a minor setback where a system was delivered with components that didn’t play nicely together. How did this happen? One team member’s point of view (me) was that a strategy for interoperability was talked about and I felt we were all on the same page on how we were to proceed. My instinctual reaction at discovering the incompatibility of the components was to feel frustration that “I was under the impression that we’d talked about doing X so why was Y done” and that additional unplanned development was now a part of an already-tight deadline. That’s my first reaction and it’s okay to feel that way. However, stopping at that reaction doesn’t address the deeper issues. The other part to this story is examining the processes or environment that led to the design and delivery of a system where two key components would not play well together. That’s a decent-sized “Oops” to have happen and I want to learn to prevent this from happening again.

At $currentCompany, we do Agile/Scrum with all the requisite ceremonies – daily standups, demos, et cetera. Standups are intended to help the team be aware of what everyone else is doing, help others get unblocked, and discuss any issues. I really like this explanation of what stand up are about from Jason Yip:

Stand-ups are a mechanism to regularly synchronise so that teams…

  • Share understanding of goals. Even if we thought we understood each other at the start (which we probably didn’t), our understanding drifts, as does the context within which we’re operating. A “team” where each team member is working toward different goals tends to be ineffective.
  • Coordinate efforts. If the work doesn’t need to be coordinated, you don’t need a team. Conversely, if you have a team, I assume the work requires coordination. Poor coordination amongst team members tends to lead to poor outcomes.
  • Share problems and improvements. One of the primary benefits of a team versus working alone, is that team members can help each other when someone encounters a problem or discovers a better way of doing something. A “team” where team members are not comfortable sharing problems and/or do not help each other tends to be ineffective.
  • Identify as a team. It is very difficult to psychologically identify with a group if you don’t regularly engage with the group. You will not develop a strong sense of relatedness even if you believe them to be capable and pursuing the same goals.

The description above captures the ideal state and I think we do well on the “Identify as a team” and “Share problems and improvements” bullet points. We joke at standups and commiserate over issues/things. However, the “Coordinate efforts” and “Share understanding of goals” seems to be where things went left as it were. In particular, I think when “understanding drifted”, standups would have been a perfect place to bring it up in order for others working on various parts of the system to be given the time to assess how their understanding of their piece changes. I’ll keep noodling on this as I continue to introspect.



Debugging a basic TypeScript app in Visual Studio Code

I’m learning TypeScript and one of the most important ‘to-do’s when learning a new language is setting up your debug environment or debugging.

Here’s how to get a bare-bones app (e.g. a helloworld.ts file that compiles down to a helloworld.js file in the workspace folder) setup for debugging. Pre-requisite to following the steps below: you have already setup your computer to run a TypeScript application successfully.

  1. Create a folder for your TypeScript HelloWorld application and initialize the folder using tsc –init (this creates the tsconfig.json file).
  2. By default (version 1.30.1), the tsconfig.json file generated does not enable source maps. A source map is a mapping from the TypeScript file to the generated javascript file (typescript transpiles to javascript). As a result, in order to debug the TypeScript code, the source map attribute needs to be true.
  3. To enable debugging via VS Code, you’ll need to create configuration for that. VS Code uses a special file called launch.json to instruct the IDE on how to debug. Per the official Microsoft documentation on debugging, you simply create one via the IDE by clicking on the Configure gear icon on the Debug view top bar. You’re not done yet though; the autogenerated launch.json file requires the following modifications:
    1. an absolute path to the TypeScript file to be debugged,
    2. absolute paths to the generated JavaScript files after transpilation from TypeScript, and
    3. setting the sourceMaps attribute to true (it’s not clear to me if this is enabled by default but better to be explicit here).
  4. Here’s an example of what my debug configuration looks like after step 3:
    “type”: “node”,
    “request”: “launch”,
    “name”: “Launch Program”,
    “program”: “${workspaceFolder}/helloworld.ts”,
    “sourceMaps”: true,
    “outFiles”: [“${workspaceFolder}/helloworld.js”]
  5. The workspaceFolder is a predefined variable you can use to construct full paths to files. In my view, using this would be preferred to hard-coding the absolute paths. Here’s the list of other predefined variables for further exploration.
  6. Now, you can add some arbitrary breakpoints to your TypeScript code, launch the configuration you just created, and observe that your breakpoints in the TypeScript file are being hit!
  7. Some issues I ran into:
    1. The value for the “program” option was incorrect i.e. pointing to a file that didn’t actually existing.
      Attribute ‘program’ does not exist

      I feel this error could be more friendly i.e. indicating the file could not be found or something similar. So if you get this error, verify that you don’t have a typo in the file name.

    2. if you use relative paths for the file location, the error you’ll receive contains a lot of guidance on how to rectify this!

      Attribute ‘program’ is not absolute


And that’s about it! Here’s my barebones helloworld TypeScript app in github and happy debugging!