Developer’s Diary 2: Good Networking

Productivity killer

I started working on an app for Dobrý Networking, and Tomáš told me, "It will be a lot of work, but your reward will be your signature on our app."

It's amazing how double-edged this information is. Yes, it's wonderful to stand by your work, to get recognition for it, and to have the chance to promote it. On the other hand, there's the fear of being (as it seems now) the only programmer on a project that will also be open-source, so the quality pressure is high. Don't get me wrong. This is just pressure I put on myself because every work I do is a part of me, and I don't want to tarnish myself with a poorly done job.

I've noticed how such a seemingly small thing can hinder productivity. Sitting at the computer in the evening and focusing can be challenging enough on its own. But what happens when you have to make decisions that might turn out to be unfortunate after several weeks of development? I weigh every decision far more carefully than usual. And that's slowing us down. Additionally, I'm an advocate of rapid development, testing, and subsequent refactoring and adjustments. But suddenly, these past two weeks have felt different. I have the fact in my head that I'm working on open source, and everyone will be able to evaluate my code. Today’s article changes this approach. My ego can't stand in the way of developing an app that helps others. Rapid development, testing, feedback, and fixing and improving will be my approach for the coming weeks.

I Love TypeScript Until It Gets in My Way

At the beginning of the project, you write a lot of code with an eye to the future. I hope the extra code I write—all the interfaces, generic components, and schemas—will make development easier in the future. Based on my experience with larger projects, I believe TypeScript works like this: As long as I don’t get into complicated types and schemas that are complex to define, TypeScript is great. It helps me as a developer catch errors that are hard to detect. For example, when manipulating data, some languages allow you to essentially ignore situations where the data isn't defined. If it doesn't break something further in the code, the bad definition just gets skipped. I'd think that’s great until another edge case prevents the entire page from loading due to a bad data definition. Proper use of TypeScript doesn't allow this. It's like a watchdog that barks at me when I try to cut corners.

Considerations and API Implementation

I spent a lot of time implementing the basic API so I could start populating the app with data, creating better user pages, and moving forward in development. Essentially, the API is a simple and handy tool. I tell our server to get me data about users, and it provides what it has in its database under the user header. Similarly, I can easily modify, delete, and create new data. It gets more interesting when, for example, you want to create an event for Dobrý Networking. Besides text fields, the app will offer a dropdown menu where you select the event’s topic. But the information about event topics had to be put into the app somehow. There are several ways to do this. We can write them directly into the code as text, create a special folder in the code to pull the information from or create a special table in the database for them. At this point, when the user wants to create a new event, I have to ask the database through the API what topics we have stored. There are several such queries in just a few user clicks, and at this point, the developer has to deal with several things. The API can't respond instantly; there will be some delay. I have to ensure the user doesn't try to fill anything out. I also have to ensure that all queries have been processed correctly and that I have all the data. Only then can I send the information to the correct places and let the user create the event. The question I was pondering is: Is it better to create a standard API and deal with the consequences I've described above, or prepare a special API for creating events that would return all the data I need in one query? I chose the standard API approach. When would you choose the second option?

The Event Creation Screen Was Created by Milan Honců

The Path to MVP and UX Testing

There’s no time to wait. The path to MVP needs to be fast and as cost-effective as possible. Below are examples of the current state. The development will flow in a similar vein moving forward. I’ll finish this very simple-looking app, and it will be used to test the app’s functionality. We’ll test that users can log in under various circumstances, that a user can create a new event, and we’ll test the options available to event organizers and how other users view the event. Constant progress and forward movement await us. Each day, a small step closer to Dobrý Networking.