why.degree

on concurrent dictionaries

2024-04-23T13:00:05+01:00

I recently fixed some simple race conditions at work, which were caused by devs who lack a full understanding of concurrency and misuse the ConcurrentDictionary from the standard library. It seems they have a vague sense that when multiple threads are involved, concurrency might be needed: the classic Dictionary isn’t suitable anymore. However, instead of reaching for a simple lock, they are swayed by the presence of ConcurrentDictionary and overlook the broader problem. My hope is that removing these structures from the library would force more people to naively yet correctly use locks and guard them from introducing bugs.

on quitting

2023-08-01T13:00:05+01:00

I was a bit reluctant to post this, but here it goes.

I have quit my job. I did it for what appears to be a better opportunity, but we’ll find out. It’s not like you can ever fully know that the grass is greener on the other side in just a few hours of interviews, especially when you are the interviewee.

Leaving a company after 2 years does raise questions about me, especially when the work anniversaries of most of my colleagues are double digits. However, the circumstances calm my — and the interviewers’ — worries down. It seems to me the older people get, the more time they spend at one company. Or at least the less flexible they are to change. Perhaps I haven’t met enough people or encountered enough environments.

While going through the lengthy employment termination process, I heard that the Department for Business and Trade suggested that non-compete periods be limited to 3 months. I took a particular interest in this document, subscribed to the updates, and successfully referenced it in an argument against the period my ex-company wanted to enforce. The timing couldn’t be more favourable. It has shown me that contracts and the law are indeed necessarily vague.

I am grateful for my time at my first job. I learned a lot about software engineering, my industry, and people. Now, I am excited about new beginnings!

on running rm

2023-01-19T12:00:05+00:00

The more software I write, the scarier it is to run rm. I double-check the path every time, and I still secretly hold my breath before hitting enter. It comes down to responsibility, experience, and confidence. The order is not arbitrary, as each is a prerequisite for the next.

It has never bitten me, and it helps that I only work on machines with my custom profiles set up. That way, I’ve got an extra check in place since I’ve aliased rm to rm -i, etc. Of course, I am training a bad habit, and there will be a time when I will have to give it up and pay the debt. Unfortunate if it happens on a production machine, but that’s why we have backups, right?

I have only recently become painfully aware of the possible effects of my actions. I knew I could wipe up everything if I typed in the wrong symbols, but it never meant the end of the world. E.g., I could rewrite my answers to a problem sheet in a couple of hours. I could also rely on git to fetch the latest stored version and implement the changes from scratch. And that is still the case for the most part. However, it only takes one un-backed up file to trigger paranoia.

I don’t expect this feeling to go away. I actually agree it shouldn’t. The further I advance, the more critical my decisions will be. So for everybody’s sake, I’d better know what to expect from each of them and be confident that it will not remove the entire company’s operating system.

on context

2022-09-16T13:00:05+01:00

I was hired right after graduating without knowing anything about my company’s field. My manager was aware of this, but they didn’t mind it. One reason could be that everyone can learn virtually anything given enough resources. More realistically, in my case, I’ve probably provided enough evidence that I wouldn’t consume too many resources before becoming somehow productive. Retrospectively, it was easy to reach that stage because many small, independent tasks didn’t require a detailed context. In time by solving them, I laid the building blocks of my domain-specific knowledge, duplicating what my colleagues already knew. Task by task, I’ve grown my understanding and managed to attribute meaning to the data my code would process. The approach has benefitted both my team and me: on the one hand, I have been constantly motivated to learn by doing, while on the other hand, my team had the time to focus on tasks requiring more context. The limiting factor of this approach is that I’ve only got so far. Same as uni, where it’s better to go through the lecture notes before attempting the problem sheet, I’ve found that learning by doing is not a sustainable learning model. To go past the barrier, I had to delve into the complexity and find the right resources to help me navigate the maze. It turns out that navigating mazes is a valuable, encompassing, and versatile software engineering skill.

Uni was great at teaching me how to learn: I’ve progressed from considering the lecture notes the professors put together as a standard to researching papers and exploring fields on my own. Besides coding, this might be the most relevant skill I’ve been taught during my degree. I remember getting upset when the lecturer wouldn’t provide their notes to the class. Coming from pre-uni school, I expected there to be a single book containing everything I was supposed to learn. I had no idea that the more you progress within the school/academia ecosystem, the less each field is standardised. At the extreme, there could be multiple candidates for a standard, each trying to prove how they’re better than the rest. I have experienced this first-hand as I’ve progressed to more advanced topics. I have even taken part in a novel course linking CS to a humanities subject, the first of its kind. I was part of the group trying to define the standard! In the same vein, my dissertation has been the one part of the degree that has enabled me to spend considerable time researching cutting-edge knowledge in the field. The goal was to contribute to research, taking it one step further by sharing my results. I didn’t get that far, but the experience was formative.

Comparing school to my professional career, I’ve started on a similar trajectory. In the beginning, it was looking at and imitating others, effectively learning to use the vaguely right language my colleagues were using. Then it was understanding the terms to their core and forming a picture of the clear, undisputed territory by going through books and manuals. Then I moved onto the edge of the technology, for which the documentation had only a few paragraphs. Even StackOverflow was unaware of my questions. It’s the stage where only a few unpopular forums mention the matter, and the discussion doesn’t progress for more than a few comments. Finally, it’s extending the picture by consolidating or introducing a vague, under-used standard. I’ve only done this for one part of my job when enhancing the company-wide translation between languages. In my short experience, all projects go through this process, but, of course, to various degrees. The moment one realises this is how learning works, the moment they start appreciating the whole process more. From the beginning until now, embracing and exploring the complexity has been crucial for my job.

On the concrete side, I remember taking the step from learning from my colleagues to learning from books. I was stumbling through the company’s library and judging books by their cover. After gathering a pile of five, I chose the one with comparatively the best online reviews. I later discovered I made a good decision, as my mentor had read and recommended that book. But even if my decision had not been optimal right from the start, I would have probably learnt some parts of the field and then chosen a more appropriate source. Books’ suggestions and references list usually give a good potential next step when my reading stack gets empty.

To sum it up, learning and getting the context keeps me going. I would hate a job where I’d be doing the same thing on repeat. Lucky for me, most software engineering jobs are not like that. They were right when they said learning doesn’t end when the degree does.

on intent

2022-07-15T13:00:05+01:00

I have argued before that writing code is like writing a story. Now, I will take it one step further and claim that reading code is like reading a story. In turn, one can see code as a method of communicating intent, explicitly, e.g. through comments, or implicitly, e.g. through data structures. On the one end, code writers must consider how their code reads from the perspective of a different programmer. On the other end, the intent behind each line may make sense to the readers only after going down the abstraction layers. Hence, coding is an art. And like any other art, beauty is in the eye of the beholder.

LifeOverflow’s video on the German criminal law related to hacking has planted a seed in my mind: how do I represent intent when interacting with the computer? It is fascinating to imagine how tech consultants need to explain to lawyers - and, in turn, to judges - why some commands become malicious in some contexts. As an analogy, it is similar to explaining why the use of knives is malicious in some scenarios and benevolent in others. A good consultant-lawyer pair would find the distinct elements in every case and tilt the balance in the desired direction, for example: by identifying the target users, what information they were supposed to access, the level of protection of the restricted data, and the level of effort it took to gain access to that data. In turn, I have become aware of how I read code: by asking what the author wanted to achieve. Take as an example the almost always auto guideline for C++. The idea is to use auto to avoid cluttering the code with irrelevant types. With a lot said about this, the gist is to ignore the rule for most cases other than the obvious ones because sacrificing reading clarity in favour of writing speed is detrimental in the long run.

Furthermore, to fully grasp the intent, it is necessary to consider aspects not directly technical, such as historical and social ones. There has recently been a case at work where I reached for a preprocessor string instead of a C/C++ string because that fitted well with the rest of the code, and I could not change everything else. A similar example is about types in Python and how older code probably does not contain any type annotations because PEP 484 has only recently seen a lot of support and extensions - PEP 673. As the last example, I have worked in a company that banned comments because they don’t add anything of value, and developers should rather spend time making their code more explicit. All of these examples show that programmers must juggle non-obvious requirements when developing software and that the functionality of their tools is not the ultimate constraining factor.

Staying on the reading side, understanding a new codebase is all about identifying the chapters and sub-chapters of intent, i.e. the main functionality behind a class or a function, combined with the meaning behind each line of code when the complete details are necessary. The trick to efficiently doing this is to start by understanding the overall story and proceed by observing how different plots and lines interlink. As a partially relevant example, understanding most of the legacy codebase I primarily work on has taken me months: one, because there are close to a million lines of code, and two, because the goal has not been to finish fast but rather to study it. Having started in a new domain, I have found that the intent behind code usually requires explanations. In this case, code has reached the status of a means to an end: I was not studying code but its use case. With that in mind, a good reason for test-driven development is that, by writing the tests before the code, one tests for intent rather than implementation details. A similar argument applies to debugging, where the programmers check how well their original ideas have translated to code. It follows that there are categories of bugs: the ones arising from a poor translation of intent skipping over details, and the ones where the shortfall is in the implementation, e.g. the ideas are there, but the specific commands and instructions come with underlying side effects and historical backgrounds. I would argue that no category is more easily fixable than the other, as both present difficult cases.

To summarise, I’ve given a couple of reasons why the unifying concept behind all coding is intent. By looking at a program through this lens, one inherits a new way of understanding codebases of any size and in any programming language. It is the intent that readers follow in a new environment, and it is the intent writers try to achieve given a set of requirements. Given an all-encompassing context, it may not be enough, but it is the biggest and most transferable building block.

on the inside

2022-06-10T13:00:05+01:00

It was during one of my internships a few summers ago I learned the dark side of tech. My company recruited one valuable early employee by directly targeting them with ads. They used every trick they were aware of to target this person: a well defined profile which included the general location of their house, their age, gender, and interests, as well as an impactful ad message that read “X, come join us!”.

The story on the victim’s side is as expected: they were constantly bombarded by these ads at each online step. They finally decided to join after considering the risk of leaving their then-job and after appreciating the amount of ingenuity that went into their recruitment. Did the gimmick take a lot of effort to set up? Not at all! It was so trivial that the company had a bank of similar, mesmerising stories.

The other one I can remember involved targeting the parents of a group of children whose school needed some donations. This campaign, too, proved highly effective. My manager at the time accused me of killing the internet by disallowing tracking cookies and using ad blockers. I might have believed them had they not killed ethics just before.

on holiday

2022-05-11T13:00:05+01:00

Taking a break from work has effects extending beyond the vacation. In the short term, the need is to check that the team can perform effectively without a person. This includes day-to-day activities but also support. Moreover, transitioning between work and non-work costs at least one extra day of readjustment, so management must plan accordingly. Long term, the duration and timing of the holidays may reflect an outburst of inner displeasure. Thus, compared to uni, the off-time involves careful planning and a high degree of communication.

I have taken time off in each of my past internships. The main reason is that they would usually cover the entire summer, so I would have almost no free time between the two years of studies. Legally, I was entitled to ~5 days in total. I would align them in such a way as to extend the holiday as much as possible (i.e. using bank holidays). In my experience, the design of most internships does not account for long off periods. It is indeed expected that some interns may progress more slowly, thus giving a small leeway. However, an issue arises when the slower interns take time off and run past that leeway. Then it becomes difficult for managers to assess the performance, so they have to rely on other criteria, e.g. the desire to complete the project. Besides this disadvantage, taking time off comes at a material loss for the interns, too: they would have most likely been reimbursed for the holiday they had not taken. Personally, I have prioritised travelling to making the most of my internships. Looking back, I believe I chose the right path. Going on vacation and returning to the same project reveals how good the team is at reintegration, something an extra week of work cannot match. To be fair, I was also lucky enough to have exciting projects and good mentors, so completing the tasks was never a time problem.

Progressing on the career path, taking time off while working full-time comes with one extra layer of difficulty and requires more communication. While the team does not depend on any of the interns, it is usually the case that every full-time member is crucial. It is essential to talk to the team and the manager and confirm that there is no risk of overrunning deadlines. If the plan is to achieve a goal in the current quarter, it would be wise for employees to plan their holidays after finishing the intensive work period. Nevertheless, covering for a vacationing colleague is trivial when the manager does not expect a lot of output in the short term. The employees can work around the time gaps and finish projects in advance if the team’s holiday intentions are announced beforehand. It is more difficult to schedule the support rota, which involves a distinct responsibility: being reachable at all times for long periods and dealing with unforeseen critical issues. As support is one of the worst parts of working with software, people may feel uneasy covering for their colleagues. The general expectation is that all employees will take some time off. Thus, generally, one good deed will compensate for the next time the benefactor goes on holiday.

From a managerial point of view, employees returning from their holiday go through a period of readjustment, thus costing the company valuable time. It would be arguably unethical and illegal to force employees to never take time off. However, the gist is that employers should include extra time besides the actual holidays in their calculations of non-productive days to correctly manage their expectations. Going deeper, if an employee schedules their holiday to effectively avoid their work, their manager has to consider their satisfaction and health. The main question both parties should address is whether the employee experiences any problems and, if yes, how their manager could help. The holiday may be the first subtle step towards somebody leaving the company. Of course, not every holiday signals displeasure, but different people interpret things differently. For example, one of my past managers became concerned when I was gone from the office for 2 consecutive weeks during an 11-week internship. Only after talking them through how I ended up taking such a long break have their legitimate concerns been calmed down. The context was that I went on holiday right after a week-long company event for the interns. It did not help that the event was a paid vacation abroad.

In conclusion, similar to other aspects of working a day job, I learned only after starting working that taking time off comes with its own quirks and subtleties. Planning the holiday in advance increases the chances of meeting all deadlines and keeping all expectations in check. Narrowing it down to only a single point, communicating about the possibility of going on holiday is about respecting and building trust with the employer, the manager, and the team.

on paper

2022-04-11T13:00:05+01:00

I believe that coding is all about following a story and implementing a narrative. Once the logic is crystal clear, it only takes a short time to transcribe it into code. Besides the obstacles the transcribing itself poses, clarifying the requirements and understanding the logic come with their unique quirks. My opinion is that the simplicity of using a pen and paper overcomes some of these issues.

It was during the first internship that I learned version-controlling. Before that, I did not have to cooperate with anyone else on code. If only from that single point of view, the internship was quite productive. Many other things I learned made the experience even better. But without deviating from the main topic, I can now look back and amuse myself with how I used to keep track of the changes in my files: using a notebook. I simulated the commits by writing down what I changed and which files I touched. Obviously, the whole system caused me a lot of pain. Going back in time by manually undoing everything was tiresome, hence why I did it rarely. I was terrified of needing a previous version. I constantly reimplemented old methods from scratch to avoid looking at what I updated over time.

My saving angel was my mentor at the time. He took pity on me and decided that I would not be able to progress without learning the industry-standard: git. I couldn’t be more grateful for their help! They have literally freed days of work from my internship. Thanks to them, I iterated faster and more systematically. In turn, I was able to ask for feedback and take my project to its final shape more quickly. I don’t remember how they figured out that I needed help, as I did not complain about my troubles. Frankly, I didn’t even know I was doing anything wrong. Not knowing what I didn’t know, I lived a decent ignorant life. Good thing there are weapons against ignorance…

Soon after that, I stopped using physical paper altogether. Whereas before I would still do maths calculations and diagrams by hand, I later discovered digital replacement tools that made me dismiss pens completely. In fact, this got so serious that I questioned whether my writing was still legible. It’s worth noting that I had a reason to care about this: physical, hand-written exams. Even for those, however, I would still practice on a computer, using the mouse and the keyboard. It wasn’t until a few weeks ago that I started using paper again when I found it easier to take notes during meetings and write down to-do lists for the next day. Quite unexpectedly, my short-term planning skills improved. I am now able to keep track of tasks more consistently. Perhaps I haven’t yet found out about a better tool for me. In any case, I seriously doubt that the versatility of a blank sheet of paper can be fully digitalised.

But the quest should not be to fully replace our striped and dotted companions. Instead, it should be to find the right tool for the right job. For example, if one requires an online, auto-syncing sticky notes app, then they should find such an app and use it. At the same time, if it’s quicker to explain decisions using hand drawings, then one should have a pen and a notebook in an accessible location, such as their cupboard. At the moment, paper is what I use for most work-related, back-of-the-envelope maths and small diagrams that I don’t have to share with my colleagues. Nevertheless, I’m excitingly waiting for the next time I’ll be one of the lucky 10,000.

on probation

2022-03-16T12:00:05+00:00

It’s recently been 6 months since I’d started working. Officially, my probation period has finally ended. As a preview, I feel more relaxed and confident about my work than when I started. It seems that my company feels happy with me as well. So we could say the probation period has been a success. I haven’t personally experienced any exam-like stress, and I don’t think there’s ever been a possibility of me getting fired. Nevertheless, I find the event worth mentioning.

In general terms, the probation period assesses one’s ability to perform on the job, both from a professional point of view and from a social one. The company is interested in questions such as: “Can the employee deliver a product effectively?” and “Do they interact well enough with their colleagues?”. Sure, the interview process must have already answered some of these. However, it’s vastly better to predict someone’s long term performance by having them do the actual job. For example, I think an internship strikes the right balance between commitment and efficiency for young developers. Therefore, the probation period can be seen as the intermediate step between an internship and a full-time position.

Similarly to most of my peers, my probation period has been highly dependent on my training. This is not the case for junior developers only: irrespective of any new employee’s experience level, they must undergo at least some training. Training I’ve been doing for half a year and training I’ll do for the foreseeable future. My mentor believes that learning by doing is correct the way to go hence why I’ve built so many scripts and tools to aid my understanding of the company’s internals. The majority of my projects have been focused on reporting and monitoring. One would mainly use these as one-off scripts. Of course, they could go one step further and add a new task in the job scheduler to run them at given intervals. These tools have taught me how to get what I need in terms of documentation and data. It is with their help I hit the first target of my probation. I can now immediately complete most tasks because I’ve transformed the job into an act of aggregating the data in different ways, according to any new project’s requirements.

The second target has been more subtle: it involved innovating. It’s one thing to implement what you’re told, but it’s a whole other thing to come up with an idea in the first place. It’s taken me significantly longer to complete this step. A few months ago, of my own accord, I started implementing a framework that would abstract away some repetitive boilerplate code. This has quickly become effective, so much so that my mentor has asked me to ship it in production. Instead of having a list of requirements or a project description, I started with a blank sheet of paper waiting to be filled. The hardest part has probably been finding the optimal place to add my contribution, which, in turn, has prompted me to understand the structure of the product. After lots of work on establishing the separation between what needs exposing and what does not, it now lives gracefully on the main branch.

Finally, I’ve also progressed acceptably in the social aspect. I am on friendly terms with literally everyone in the company. Having been on a company trip has definitely made it an easy target. I would have otherwise had to schedule way too many coffee breaks and lunch trips. The company is naturally relatively small, but that only shows that I have to interact with almost everybody else. With all in mind, I am on a theoretically decent trajectory that will hopefully turn out accurate. With so much time and so many resources consumed, it probably will. Even though the exact details of the probation period can differ between companies, the general points are always the same: understand the culture and the tech, and it will be fine.

on training

2022-02-15T12:00:05+00:00

It took me 4 months to get access to master. Two weeks later, I got access to the privileged user as well. Did this take too long? Should I have asked for more responsibility? It ultimately narrowed down to my experience and my team’s impact.

See, our team consists of yours truly and his mentor. That’s it! Two people are in charge of the most critical part of the company. Until I joined, my mentor had been the sole programmer for two years. For two years, this person’s dedicated everything to keep the product going. They’ve also been on support all throughout this time. The bus factor, in this case, was 1. Sure it’s not ideal, but the company couldn’t afford to hire anyone else. And when they could, it was a junior: me.

Their reasoning was that training someone with zero field knowledge is better and cheaper in the long term than hiring an old fox. On the positive side, the junior would provide outside-the-box ideas, having never encountered the field-specific limitations. They could also learn the field based on the in-house technology, so there wouldn’t be a need to adjust from previous experiences and manage previous expectations. As for the negatives, it might take longer for the new guy to learn a new field than it would take an experienced developer to adjust to a new company’s stack. The company’s ~~perfect~~ bus number would grow in either case, but I’m not veteran enough to know how the growth rates differ and what impact that has.

In any case, what’s done is done. This post is not about justifying past decisions, especially when they’re not mine. From my perspective, it’s like I’m doing another degree. Much different to the official one, I must say. I’m getting the most personalised teaching and curriculum out there. All my coworkers are eager to answer my questions, thus motivating me to get to their standards. Nobody expects me to reach that level any time soon, as this is just the long-term target. I still work with a manager, do reviews, open and close JIRAs. But I am the one who sets the pace for most of these. And the company respects and values me for that. In turn, I value it.

So how can someone join a team and not be able to contribute to master? Well, my mentor merges my branches in my stead. However, when a change doesn’t require a review, I do it myself. I still want my mentor to review 99% of the code I write, as their comments are really insightful. It will probably take one or two more years before I’ll confidently say I’ve learned most things and my training’s ended. But that’s fine for me, and as far as I know, that’s fine for my employer.