Web Developer Intern

Summary

This is the second internship that I had. For most of the internship period, I was responsible for leading a team of fellow interns to work on the front-end of the company homepage. I wouldn't say it's particularly satisfying or exciting. But it's also not terribly awful.

Developer Diaries

Making a Homepage (Again)

If you were to look back at the previous entries in this works sections, you'll notice this is all that I've been doing. I had become quite bored of it at this point because frankly, at least for most homepages that are out there, there simply aren't that much to it. Usually, most of your work will consist of front front-end development with comparatively light work in the back front-end (thanks mostly to the use of front-end framework). Exception do exists, concretely I can point to the homepage of this marketing firm called Fleava where I am sure considerable work were put into writing Javascript, but they're not common. You're not learning much back front-end (aside from perhaps the best way to organize, structure, and abstract your UI components) which is a bad thing because it is the side of the front-end that actually uses a programming language. This is in contrast to making a full-fledged application that lives on the web, such as the many projects I have done in the other section of this site.

The things is though, my previous experiences making a homepage taught me a new thing each time: AIChe gave me a taste of leading and working in a team; TEDxITB gave me the experience of having to delegate my tasks to subordinates and more intense high-level coordination with non-tech stakeholders; KiteSense and Asa, Cerita, Wanite taught me more advanced front-end development techniques (mostly CSS black magic). It's redacted from the server-side, do you think you're so clever? It's redacted from the server-side, do you think you're so clever? It's redacted from the server-side, do you think you're so clever? It's redacted from the server-side, do you think you're so clever? It's redacte Why these are the case should be obvious by the end of this text.

A Bubble of Interns

One of the most notable It's redacted from thing I experienced during my time of employment here is how the interns is placed within the company. There were a handful of interns that the company hired to work from July to December, including me, and these were most of my co-worker during the internship period.

For reasons that I don't know, the company decided to It's redacted from the server-side, do you think you're so clever? It's redacted from the server-side, do you think you're so clever? full-time employee of the company is the only interface through which the company communicates with the interns. As far as the interns are concerned, the company only consists of these few people It's redacted from the server-side, do you think you. In addition, the work that we had done were almost detached to the internal work done to the company's main product. For example, the homepage that we were developing for most of the internship period was entirely from scratch. The repository was new and the tech stack was chosen mostly by the ourselves. We weren't adding new functionalities or features to the company's existing homepage, we were making an entirely new one.

This It's redacted from t is somewhat difference from Kitesense. Although the work I did there was similarly detached from the company's main product, in Kitesense I still could communicate with anybody in the company through the company's Slack. It's just that, due to the nature of my work, I seldom need to do that. Here, that barrier It's redacted fro.

Maximizing Difference and Cutting Bloat

It's redacted from the server-side, do you think you're so clever? It's redact the internship did gave me the following two lessons. The lessons here should really be common sense, It's redacted from the server-side, do you think you're so clever? It's redacted. They are best conveyed by this excellent video from Primeagen. There are a lot to be taken away from the video, but there are two of them It's redacted from the server-side, do you think you'r: your work isn't guaranteed to make a difference (but it should!) and the danger of task bloating.

The "difference" I'm talking about here isn't the grandiose definition difference that most people uses when talking about making a difference. Something as simple as sweeping the floor makes a difference: the floor is now cleaner. For a long time, I have always thought that my profession is one of the profession where the difference created by our work will almost always be apparent. Every lines of code we wrote surely has to manifest in the feature enjoyed by the end-user or an improvement to the business process of the organization using the product we developed, or so I thought previously.

But It's redacted from the server-side, do you think you're so clever? It' that's not the case. Not everything that we've done will actually be of use to anyone. This point is highlighted in the latter part of the video where a company hilariously created a tool for data scientists without consulting with any data scientist, resulting in a product that likely won't be used by data scientists. The team working on that product is observed as having little morale because they know that the product they develop doesn't benefit anyone.

Additionally, I now became more aware of the considerable amount of work in the software industry that can be categorized as 'meta work', as described by the aforementioned video. These are tasks that don't actually culminate or results in anything, i.e. not making a difference, but makes the team or the organization thinks that productive work is being done. One of the example given, and in my opinion the most apparent category, is standup meetings. I am not saying that standup meetings are useless, but I think its very nature of taking place every day could negatively affects all of the participants involved. Because it occurs every day, it gives an illusion of work, as said previously. But another effect that I see is that it gives an illusion to the team manager or leader that proper control is exercised within a team to ensure their tasks are done in a timely manner. It's redacted from the server-side, do you think you're so clever? It's redacted from the server-side, do you think you're so clever? It's Which brings me to the next lesson learned.

People of this profession is not the best when it comes to estimating the time needed to complete a task (which I think actually applies to a lot of other professions, not just tech). So you can imagine how even more atrocious that estimation would be when it is done by people outside of the profession. The video corroborated this fact and chalked it up as one of the big reason behind task bloating, where the time estimate for the completion of a task is inflated. I would add onto that by highlighting the lack of any business pressure to release a product as another reason for task bloating. A businessperson (the sort that I am talking about here is one that isn't remotely familiar to the technical side of things) really could only give "business" reasons as to why they demand a task to be completed within X timeframe, such as needing to beat the release date of the competitor, having to submit the code to auditor before X timeframe, or that another team at the company urgently needs the product being developed to do its job. But when there is no actual urgency to complete the product you're working on, it's highly likely that a businessperson will accept whatever number that the engineer is throwing at them. Because at that situation, the only constrain on the task is the technical difficulty of it, and the businessperson certainly isn't going to make technical arguments as to why centering a div doesn't require 2 weeks to complete. I guess the main takeaway here is that the task of leading and controlling a team of engineer should be delegated to an engineer as well, because they possess the know how to make those technical arguments and form a tighter time estimate.