The things I would like to look at today aren‘t specific to the project I talked about. It’s more that the situation in the project caused me to think about them. I‘m going to list some tools and infrastructure that I think is essential to (remote) teams. Of course the topic isn‘t new and lots of people have written about it but I still wanted to share my thoughts on it.

What are these tools?

• A shared backlog. This is typically an issue tracker like Github, GitLab or Jira. Don‘t make it to complex, simplicity wins here. Jira for instance has tons of options to define workflows and constrains on entries, I never found these any helpful and at best annoying. Keep it simple, small teams will figure out how to use them for themselves.
• A campfire. Usually this is an instant messaging tool like Slack, Teams, etc. Useful for instant communication where you expect an answer in near realtime. Make sure it supports threads. I‘m personally not the biggest fan of threads in general but for doing „asynchronous meetings“ they are really useful when used with caution. Don't forget to have a “yammer” channel in there where you can complain about things.
• A binocular. A video chat tool which the team can use for their meetings when they are not asynchronous e.g. a daily meeting to checkin with the rest of the team. This could be integrated into your campfire or something external like google meet or whereby. Make sure it supports decent screen sharing. When on boarding or coaching remotely there nothing more annoying than not being able to see what the other party has on their screen. Decent means it should be responsive and ideally have support for the viewer to markup parts of the shared screen. And no ancient tools like Skype for Business don‘t cut it anymore.
• A library. A place where to put longer writings and get feedback on them. While video chat and instant messaging are useful for a quick conversation and getting questions answered quickly, there is a place for longer pieces of text. These pieces of text might be concepts, ideas or rules the team has given themself. The content of these documents are usually long living and something you want to store in a structured and searchable way. Refining a long concept over instant messaging can be quite a pain. Tools for this should allow annotating the text and should have a comment system so that documents can evolve. Tools like basecamp, confluence or other wikis work well here, Github wiki didn't in the past because it's missing a way of providing direct feedback.
• A storage house. A place where to store larger files that aren't source code or directly related to the codebase but still relevant to the team. We often use this to share recordings of training sessions or introduction videos but it can also be useful to share slides and other material like that. Tools like Dropbox, Box.com or similar are useful here.

These are the five essential things I think a (remote) team needs. The exact details of some of these tools might vary depending on how the team works and which ceremonies it follows but I think you will find these in one from in the team. Another important thing it that all these tools should be accessible over the internet, no VPN or intranet stuff.

You might ask yourself why I didn't mention source code repositories or continuous integration servers. I think these are tools that don't extra mention in the year 2020, it's such a basic infrastructure that I don't think it worth mentioning them explicitly.

What about you? What do you think are essential tools for teams? Did I mis any?

You want to join the conversation? Drop me a tweet @dumdidum or email me at kolja@hey.com

The Helios is pretty easy to find on Ebay or other marketplaces since it was produced so much. The prices for the lens are usually cheap, I got mine for 34€, though they increased a bit in last year. There is offerings for like new lenses which were opened and cleaned but as long as your copy of the lens has no fungus you should be fine. If you want clean it yourself the lens is simple to (dis)assemble anyway.

I own a Helios 44-2 which is the M42 screw mount version of the lens. The first thing I found strange was how the aperture works. The aperture is controlled with two rings instead of one. The upper ring allows you to set the aperture opening you want and then a second ring below allows you to actually open and close the aperture up to the value you set with the upper one. Sounds a bit complicated when written but in practice you get used to is easily. The aperture ring is clickless, you can dial any value that you like or do smooth aperture pulls in video. The ring that moves the aperture isn't damped so getting smooth pulls requires some training. If you get a 44M is has a classical clicking aperture ring.

I got my lens about three years ago mainly because it was cheap and I wanted to play around with a bight somewhat telephoto lens on my Sony A68. The A68 is a APS-C camera that means the lens is roughly 90mm in focal length. I quickly discovered that 90mm isn't really interesting to me. On APS-C it was hard to get a the swirliness of the bokeh to show, you had get a in very specific sweet spot between focus distance and object to background separation. The lens quickly disappeared in my camera bag and was rarely used.

About a year ago this quickly changed. Two years ago I bought a full frame mirrorless Sony A7, yes that first A7 not the MK2 or MK3, the one with crappy autofocus. I didn't touch the Helios much for the first year because I almost forgot about it and I hat no M42 screw mount adapter for the camera anyway. At some point I decided get one again because I remembered that I had the Helios. At that time I was missing a full frame lens between 35mm and 70mm. Since I never really liked the look of 50mm or 35mm on APC, I have always been in love with 35mm, I decided instead of buying something new or used native to E-mount to get the adapter.

Since then I used the lens a lot. I like the 58mm look a lot, it's a bit more zoomed in that the usual nifty fifty. Of course the lens isn't a modern optical design, it flares a lot, its contrast and sharpness wide open aren't amazing and the micro contrast always remain low when compared with modern lenses like the Sony 24-105mm F4, which is a sharpness and micro contrast beast even “wide” open.

The Helios has its own personality, it's not a tool that will allow you to reliably reproduce pictures under similar condition and it requires to get used to its flaws. But the lens produces vivid colors and usually sharp enough pictures especially for portraits.

Since I do cooking stream a lot lately I use the Helios for taking pictures of the food I cook. The focal length and minimum focus distance are good enough for my kitchen and since it's F2 I can throw in somewhat bokeh easily. Sharpness and contrast aren't to much of a concern here because the pictures aren't used at full resolution anyway.

Apart from the food use case, the Helios is right now the default lens on A7 when I just take the camera with me. Sure it's not as versatile as the 24-105 F4 Sony but it also doesn't come with same heft to it as the Sony one. One of my favorite picture, a portrait of a mushroom, was taken with the Helios:

The lens pairs nice with still life pictures like these from my tea corner.

All in all I really came to like the lens and the focal length. It seems like modern lenses don't cover the around 60mm focal length, the closest for Sony is the Sony 55mm F 1.8 ZA which I might give a try. It might be that there is no real difference between 50mm and 60mm and I just tricked myself in to liking “standard” lenses because it's not so much standard. What about you, do you have weird focal length or vintage lens you like a lot? Feel free to drop me a tweet or a mail (see below).

You want to join the conversation? Drop me a tweet @dumdidum or email me at kolja@hey.com

Does that mean the juniors are hurting the team and they shouldn't be part of it? I don't think the answer to this problem is that simple.

Looking at what seniority in this project means its falls into three categories:

• Experience as a software developer. This simple to grasp it's essentially how much time has one spent as a software developer, how much experience do you have working in teams, etc.
• Experience with the technology. In our case we are developing a domain specific tool for the automotive domain. As an implementation technology we are using JetBrains MPS. Experience with the technology means two things for us: how good do you know your way around in the tool and how much have you developed a language engineering mindset.
• Experience in the domain. In our case that is automotive. How well do you know the “language” spoken by the domain experts and how long does it take you to understand their problems.

Now looking at how the team is structured we find three “buckets” in the team: one group is people with 10+ years of experience as a software developer, 5+ years with MPS and language engineering and 2+ years in the domain. Another group has 2-3 years of software development experience and the same on language engineering and MPS while their domain experience varies between 2 years and 6 months. The third group has at most 6 months in all of the categories and it's often their first job.

What is the problem? On paper such a team looks good, there are senior people from whom the junior people can learn? To sum it up in one word: frustration. Especially for people like me, where intrinsic motivation is very important, seeing that we as a team don't make meaningful progress on the product is frustrating. Doing sprints where the biggest challenge is to explain to parts of the team basics like git or Java becomes exhausting overtime. It's accompanied with the feeling of never achieving something meaningful in the project. I'm a person who likes to push myself by over committing. I'd rather set a goal that I can't reach and push myself to get as close as possible to it, than setting lower goal thats “safe” to reach. If I set a lower goal where I know I will reach it, it's boring to me and it doesn't feel like an achievement to me when I reach it. Setting such goals in a team with this asymmetric skill level is almost impossible.

Right now we are approaching a state where the senior people are about to get burned, or better to say bored, out because they are missing a challenge and don't see how the situation allows them to develop them selfs further. To make it worse there is no obvious solution on the horizon. The business has expectations about shipping features which are not to meet if the seniors leave.

You want to join the conversation? Drop me a tweet @dumdidum or email me at kolja@hey.com