rcd2

Hi. I did well in school, but I don't do that well at work. Just recently, my manager told me I fail to see the big picture.

School was easier: the path is laid out for us and we just need to, more or less, follow it. At work, not so much. Everything is ill defined and you're sort of expected to "learn by osmosis" (by going to meetings, listening to your team chatting and then forming an understanding). I'm terrible at this and the consequence is that I don't always prioritise my effort and work well.

The obvious answer is to ask, but I'm not always aware of what I'm missing or the explanations come with loads of other lingo and assumptions about my current knowledge. After failing to understand an explanation, I feel I shouldn't ask again for fear being labelled "dumb" (after all, everybody else seems to be doing well). I also try to take notes, but after a while I just end up with a pile of disjoint pieces of information.

Has anyone felt like me? Have you found techniques and strategies to cope with this that you could share?

Or anything really. Points of view and opinions are very much appreciated as well.

Hi! Very often I seem to struggle to get anything done when I’m working on an unfamiliar subject, specially when I struggle with the documentation. This is not a rant about bad documentation, but an attempt to learn about some stories and strategies from people that can always seem to get things done even in a situation where the documentation isn’t for total beginners and they don’t also have the correct background.

A good example is Prometheus. I struggle with their documentation, but I feel I’m missing some background knowledge as well, but I don’t even know where to get it.

Another one is AWS. I’ve tried to use AWS ECS with an EC2 launcher but I failed to do it by myself. I later found a GitHub example, but I really don’t know what I’m doing.

How do you get your work done in these situations (let’s assume the final answer is not just a couple of Google searches away)? Do you just go down the rabbit whole of whatever seems to be the required background knowledge? Is it trial-an-error? If so, how do you it’s done right and you’re not overlooking anything major when you don’t understand all the variables involved in the problem?

I hope this question isn’t too vague and you’re able to understand the kind of advice I’m chasing.

Although I understand its mantra, I was never able to “drive the design” using TDD. To highlight my issues, let me share a recent failed experiment.

I have been trying to create a command line tool to categorise my expenses and show a total by category. I’ve been using this exercise to practice TDD.

In my latest frustrated attempt, my first test was along the lines of “it can categorise a single transaction correctly”. The problem with this is that this is testing the “tip of the iceberg” that will be almost the whole, final app. I think I was attempting a more “top down” design strategy here.

Before that one, I tried the opposite: a more “bottom up” approach. I know I need to, at least, read a CSV, parse a CSV row into some data structure and then categorise it. So I TDDed my way through to complete these “sub problems”. However, when I was about to apply the categorisation rules I realised that the data structure I created didn’t help, was just bad and didn’t work at all :).

So, how do you do it when you have a “larger project” (here, “larger” means something that’s not your typical “2/3 points user story” at work)? I always end up feeling stuck whether I try bottom-up or top-down.