Posts
-
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.
-
I was a bit reluctant to post this, but here it goes.
-
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. -
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.
-
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.
-
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!”.
-
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 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’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.
-
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.
-
I haven’t done interviews in a while, but the idea of interviews is constantly present in my mind. The #1 question almost no company seems to get right is “What would a perfect interview look like?” I suggest that a good approximation for software positions would be to evaluate three general skills: problem-solving, communication, and flexibility. Although the skills are pair-wise intertwined, a candidate should be visibly good in each of them to easily integrate into an existing team. The generality should not be a concern, as the employer still has the liberty to tailor the process to their domain by presenting domain-specific problems. This achieves a balance between abstractness and concreteness while also satisfying both the employer and the potential employee. The process goes as follows.
-
Having lived in one repository for a few months now, I have naturally grown more and more accustomed to it. I am currently at a stage where the challenging part of adding a new feature or fixing a bug is merely talking about the solution. It’s not that understanding the details and the impact of my work was trivial before; it’s just that the actual implementation has definitely become more approachable. With every new project, I can spend more time focusing on how it would fit in the overall system rather than how to write the bulk of the code.
-
During the first couple of weeks of work, I was obsessed with getting tickets finished in the least number of days. To be completely honest, I actually counted the number of tickets I completed in a week and compared it to previous numbers. After bringing myself down one or two times, I realised quickly that this unhealthy exercise is not perfect, as some tickets are intrinsically more complex and take longer. With fresh enthusiasm, I decided to change the metric: from the number of tickets per week to the number of lines of code per day instead.
-
I spent my entire degree not knowing the difference between workdays and weekends. I studied on most Saturdays and Sundays, and I took time off whenever I felt like it. Did I have the most organised schedule? Clearly not. But it was the flexibility I was after. I could have attended any event at any time of the day just fine without any repercussions on my work. Fast forward a few months, full-time work mode is on, my calendar is booked Monday to Friday, 8am to 7pm, and I had to learn to separate work from life. Let me explain.
-
There exists only a limited number of genres that I can listen to while coding. Most songs with vocals are way too disturbing, and I can still not concentrate even if it is, say, the violin that plays the vocals. Like the rest of the Internet, I’ve had a positive experience with lo-fi hip hop for a while. Like the rest of the Internet, I’ve grown too accustomed to it.
-
Hacker News is a great community for all things technology. It’s the place where I spend most of my free time, always impressed by the various people I get to meet. And so, with the mandatory excuses for directing my attention to such earthly matters, I wanted to check which users are the most active on the forum. The connoisseurs out there might already think https://news.ycombinator.com/leaders, yet that was not enough for me. I didn’t want an all-time, static ranking; I was interested in the most active people at this specific moment. As I could not find what I was looking for anywhere, I decided to build it myself. Now I can find the users that showed a huge engagement recently, the users that have something important to say. Check it out here: https://why.degree/hn-top/.
-
Technology evolved and developers can not understand everything anymore. So how does the world survive then? People specialise, that’s how! After you finish your degree, you don’t train to become a Computer Expert, but rather you focus on one area in particular: databases, security or WebDev, for example. Everyone knows that, yet not everyone knows all of the possible options from the start of their career.
-
Young developers are different. They were taught to have Stack Overflow up all the time, to have a working environment set up in minutes and the firewall turned on by default. Taking this last example in consideration, I can attest that’s right. Until the Networks course, Windows Firewall and Uncomplicated Firewall on Linux was the furthest I have ever explored the system.
-
Extending on the about page, I want to emphasise even more the importance of creating personal projects, having independent work and going far beyond what a degree might teach you. Just so that we are on the same page, I will not take into consideration the reason for choosing a Computer Science degree, nor the money aspect of doing a degree, but rather I will assume only that you are doing a Computer Science degree and my focus will be on how to make the most out of it.
subscribe via RSS