Audio-video setup for meetings and videos

This post is part of a series on demonstrating competence and expertise on video:

So you want to show expertise and competence on video…

Recording a technical talk? Creating a video about a management tool, to be used as an advertisement for consulting services? Working on the perfect conference talk for an online conference, hoping to gain another 1000 Twitter followers among the community using a library you work on?

These are all cases where demonstrating competence and expertise in a video, to an audience who can leave with one click at any moment, pays off. Here are tips I have found around the web and from my experience.

Continue reading “Audio-video setup for meetings and videos”

Coding together – continuous technical community

I was thinking today, observing how our multiple teams (spread across many customer projects) at Oasis Digital and Expium collaborate. There is an interesting pattern of collaboration that spans the very different types of work at these two firms I’m involved in.

For background, the work at Expium is all about Atlassian products, and the work at Oasis Digital often touches Angular in some way, in conjunction with other full-stack technologies, because we are most well-known for Angular. I don’t think today’s thought really depends to any specific technology, but I’ll tell it from a software development point of view.

We have been using Angular for about as long as it is possible to do so. We started back in the Alpha sequence and have built a great amount of code for many customers since then. We’ve trained thousands of developers. And personally, I have written a lot of Angular code, including code used in teaching Angular Boot Camp, which means it is example code, very heavily scrutinized and polished.

Continue reading “Coding together – continuous technical community”

Full stack Angular – live coding – talk notes

I spoke (and live-coded) at the Advanced Angular Lunch in St. Louis, August 2019. The talk description:

Watch or heckle as Kyle from Oasis Digital live codes a full-stack Nx + Angular + Node + Nest + GraphQL project, with concurrent explanation and Q&A along the way. Mistakes will be made, and perhaps corrected. Lessons will be learned, but perhaps forgotten. You (might) see the productivity possible with “full stack Angular” – but this is real live coding so anything could happen.

Continue reading “Full stack Angular – live coding – talk notes”

Maximum productivity when you are the bottleneck

Scenarios that make you scarce

Software development productivity is the ratio of desirable high-quality software to money spent. With this meaning, productivity is aligned with quality and effectiveness: it only counts creating “the right software” and encompasses creating “the software right”. Productivity is more important than efficiency (the lack of waste), as occasionally a bit of inefficiency pays off.

In the quest for some combination of these values, project management methodologies or practitioners generally assume that members of a team have approximately similar scarcity/availability/cost. But sometimes, you may find yourself more scarce than a group you are working with:

  • You are leading at a high “fan-out” – one person leading a team of many.
  • You are leading a team expected (for good reasons or bad) to expand or turn over significantly.
  • You are much more senior than the rest of your team.
  • You are in an expensive city or country, other team members are in a less expensive locale.
  • You are a “hired gun” consultant, brought in at great cost, expected to “move the needle”.
  • You are a professional developer responsible for mentoring, teaching, and getting results from a group of interns.
  • You have a communication advantage with the customers of a product or project; perhaps you speak the customer’s language more fluently than others on your team.
  • You are the only team member with extensive and relevant experience to the problem at hand.
Continue reading “Maximum productivity when you are the bottleneck”

Angular dependency injection: why?

At work we teach and consult on various topics, notably (for this post) Angular. We are often asked why Angular has and heavily uses dependency injection. Here are my answers to this question; I haven’t had a chance to compare notes with the rest of our Angular expert team, so here it is, on my personal blog. (However, special thanks to Paul Spears, who helped clarify these ideas.)

Dependency injection has a considerable complexity cost, so it’s important to have good reasons to add this complexity to a framework or application. There are an unlimited number of potential features and patterns to follow, so the default for any particular feature or pattern must be “no”. Moreover, popular Angular alternatives (like React) thrive without a dependency injection system, constituting an “existence proof” that it is not a necessity, but rather a choice.

Continue reading “Angular dependency injection: why?”

Populate your issue tracker at scale

Sometimes when working on a project at work, we find out about a pile of features or changes needed. This can happen at the beginning of a project, at the start of the major initiative, after deploying a project (which triggers much user feedback), etc. Sometimes we have so much to absorb and divvy up into issue tracker items, that the logistics of doing so are painful.

Just thinking through and writing down 50-100 issues (or more!) is too tedious for one person to get through quickly. To divide up this work (of describing a bunch of issues in enough depth someone could work on them), I’ve come up with the following approach.

First, I jot down a list of all the areas of the system where there are new issues to enter. This forms an outline of areas that have issues, I don’t even attempt to make an entry for every likely issue.

Second, I record one or more videos, showing the screen of the system I want to add issues for, alternating back and forth with code. As I go, I describe each problem/opportunity/fix, that should become an issue. Depending on whether the new issues are closely related to existing ones, sometimes this includes bringing up the issue tracker (Jira, etc) also, talking through existing items about work remaining on them.  Sometimes something that first seems like a new issue, is really just a refinement of the success criteria of an already known issue.

Having spent potentially quite a while just describing issues (there have been times when this goes on for over an hour), I hand over the recording(s) to a relatively new person on the team, who will go through and translate this rapid-fire description into a set of items. Typically it’s fastest for the person to do that not by directly entering the items, but by just typing the candidate issues into a document. (If the list is big enough, it can pay off to have a transcriber handle the first pass – turn the words from the video/audio, into text.)

Finally, that initial rough list of candidate issue, goes to the project leader(s) of the project in question, to clean up, refine, review, approve. Then someone copies the approved text into the issue tracker.

Admittedly this is not a complex process, hardly worthy of a blog post. But someone once asked me how we successfully enter so much detail into so many items on complex projects – and here is the answer. Entering all that really does pay off. It is much more plausible to delegate work if you have described it as thoroughly as you can.