Forem: Yves Gurcan

Daily stand-ups done right

Yves Gurcan — Sat, 12 Sep 2020 21:44:22 +0000

You probably heard about Agile and Scrum. Maybe you said to yourself that it wasn’t for you. Fair enough!

The beauty of these methodologies is that you don’t necessarily have to go all-in to reap the benefits of a better workflow. Don’t feel like hiring a Scrum master yet? Retrospectives seem like a waste of time to you? Ok. Why don’t we start with something small but which will have a huge impact on your day-to-day work life: stand-ups.

What is a stand-up meeting? To put it very simply, it’s a recurring work meeting where all participants share 3 things: What they did since the last stand-up. What they will do until the next stand-up. The blockers that are preventing them to progress on a particular task.

Despite the name, stand-ups don’t have to be funny (insert comedy drum punchline sound here). It’s probably better if they aren’t, actually, but feel free to crack a joke, especially on Monday morning 😉.

Stand-ups don’t have to happen every day either. Some teams are more comfortable with meetings every other day, twice a week, or even once a week. Doing a stand-up more than once a day might be overkill. Your teammates need some time to dig into the problem they’re solving and hopefully you can trust that they will communicate if they are encountering new obstacles throughout their day. The frequency of these meetings should probably be discussed as a team.

There’s no need to stand during the meeting either, really. Especially on a remote video call! If you’re doing stand-ups in person, though, it might be best to gather in some sort of circle. Either by somebody’s desk or in a conference room where the table isn’t in the way or, even comfier, in a lounge area with sofas and chairs. Nice!

Meeting in a circle is important because each participant takes a turn to talk about what they did, what they will do, and blockers. Typically, one person volunteers to start and then the person next to them (clockwise or counterclockwise, depending on your preference) takes a turn, until we reach again the teammate who spoke first. One of the points of stand-ups is that the meeting isn’t run by somebody in particular. The stand-up should be a one-to-many relationship (where the person who is talking is sharing the information with everybody) instead of a one-to-one relationship (where each person in the circle is only talking to another person in particular). In other words, it is not recommended to have the meeting centered around the team lead or the Scrum master. This nuance plays actually a big role in giving your teammates the means to be more self-sufficient and involved. If you’re meeting over Zoom, for example, you can either ask your teammates to volunteer one after another until everybody has spoken, or you can ask the teammate who last spoke to designate who goes next.

Having a TV screen, an ultra-wide monitor in sight of all the participants, or somebody share their screen is also a huge visual aid for the whole team to follow what the person currently speaking is referring to. But that will only be useful if you have a tool like Jira or Asana to keep track of tickets and issues that the team is working on.

“Who participates in stands-up?” you might ask. Well, the short answer is: everybody! Stand-ups typically happen at the team level. Developers, designers, DevOps, product owners, team leads… if you want to maximize communication, you will greatly benefit from having all co-workers focusing on the same project to gather together every day. Having guests who can be particularly useful on a pressing issue might also be super helpful.

How long is the meeting? Don’t worry! Stand-ups are meant to be short in nature. Fifteen minutes is a standard amount of time but it’s also normal if it goes over. If it constantly lasts more than 30 minutes, though, you might want to think differently about either the structure of your team (too big?) or the dynamic of the stand-up. If a particular conversation becomes too detailed or the participant is rambling, scheduling a meeting with 2 or 3 attendees could make more sense than keeping the whole team captive about the problem.

Tardiness is a big deal. A stand-up is the best way for the whole team to be aware of what is going on with their teammates. Being late is utterly disrespectful as it may convey the message that the person doesn’t care about the rest of the team. Even worse, they might waste their teammates’ time by asking them to repeat what they said earlier. Please don’t let that kind of behavior happen regularly.
Starting too early can also be problematic for the same reasons. Make sure to wait that everybody is here before starting the routine to avoid communication gaps. Nothing wrong about asking how your teammates are doing, though, and tell them the amazing hike you did last weekend.

So, I told you about the what and the how of stand-ups, but what about the why?

I have sprinkled some of the reasons that make stand-ups a powerful ritual for your team: It promotes self-sufficiency as well as good and efficient communication. With a 15-min time commitment, you will gain much more visibility on what your team is doing, thus giving you the right tools to alleviate pain points and make your teammates’ life easier. Streamlining this process will make stand-ups a routine that kicks off the day in great conditions.

You already adopted stand-ups? Excellent! It might be the right time to reflect a little more on this meeting, then. Are stand-ups giving you the information you need to help your team? Are participants mindful of everybody’s time? Are there extended periods of time where you’re in the dark about possible problems that are hindering your team? If one of your teammates is not present at the meeting, does the stand up run smoothly?

A few tips for effective communication

Yves Gurcan — Sat, 04 Jul 2020 22:34:44 +0000

Are you feeling like you're sometimes wasting your time at work? Are people not answering to your messages on Slack? You're tired of all-hands meetings? Often, it does not take a huge investment into a new third-party platform to improve processes in your company. Simply improving the way you communicate can go a long way and provide immediate results. Thinking about the right words when you need something from someone else can completely change how you feel about your day-to-day activities.

Try out these strategies to communicate more efficiently with your coworkers:

Get to the point. Starting a conversation with nothing else but "Hi!" and waiting for the other to respond with a greeting before going further does not do much for you, does it?
Improve the "responsability" of your messages by asking a specific question. The recipient will be more likely to respond if you ask for their input directly and your question is focused.
Avoid sending messages to everybody unless it's an announcement. Only involve key persons in the conversation. Thinking about who you would like to talk to helps you understand better what you want to communicate about. Is your question related to project management, HR, or a specific application? If you don't know who the right person is, that's a great question in itself. An educated guess will be more fruitful that a message sent to all the members of a mailing list! If you really have no clue, ask a coworker or your supervisor. Make sure to take note of who your interlocutor is for future questions.
Nothing is more frustrating than a message saying "It's broken." and nothing else. Do your homework. You found a problem? Great! Don't expect others to solve it for you. If you found the answer by yourself, you will not even have to communicate about it. You won't have to wait for the person to free up time for you and you will learn something new.
Offer alternatives. What do you think the problem is? Have you researched possible solutions? What did you find? Did you examine the pros and cons? Are there other approaches you can adopt? People feel less frustrated and scared when you provide a plan B instead of ending the conversation with "That's not possible."
What is the next step? If your question necessitates a meeting, give two or three options for a time, day, and place. Make sure that you prepare before the meeting so that this time is focused on your question and nothing else. If you need some time to think about it or gather more information, tell your interlocutor when you will get back to them. In an hour? Tomorrow? Next week? Keep the conversation going. Make sure to follow up when you said you would.

Pro-tip: These principles also work in your personal life :)

Problem solving: Mike Acton's tips for game industry programmers

Yves Gurcan — Mon, 18 May 2020 20:33:28 +0000

In an excellent GDC talk from 2019 called "Everyone watching this is fired: Tips for game industry programmers", Mike Acton gave incredibly helpful insight on what he obviously considers the best approach to solve technical problems.

Even if his presentation was geared towards game developers, I found that his advice also worked very well for other fields that involve programming such as web development or even, to some extent, to common life problems. I couldn't resist the urge to apply his 50 tips to a project I had recently kickstarted for one of my clients.

According to Mike Acton's standards, I would have indeed been fired. Good thing my clients are more forgiving than him 😉. The part that got me was the one about the acceptable ranges of the values I am transforming. Despite using strongly typed languages and frameworks, I had not thought deeply enough about input validation and realized that I might have allowed users to enter negative amounts in this invoicing system which, you can imagine, would have screwed up things. Phew, that was close.

I found myself very inspired by the video and decided to templatize (yes, "templatize" is a word, the Urban Dictionary says so 😛) Mike Acton's tips for my own projects starting now.

As a consequence, I've created a table of 31 questions (see below) that must be answered before starting writing a single line of code on a project at Parallel45. A very useful tool that is already improving the quality of our work and make our clients even happier!

Thanks, Mike!

#	Question
1.	What is the problem I am trying to solve?
2.	Why is this problem important to solve?
3.	Where is the limit where solving this problem is not worth it?
4.	What is plan B?
5.	What are the steps required to solve this problem?
6.	What are the unknowns and risks associated with the solution?
7.	Which framework I created can I use and modify to solve this problem?
8.	How do I know when I'm done solving the problem?
9.	What am I trying to prove? What is my hypothesis?
10.	How can I prove my hypothesis is wrong?
11.	What are the latency requirements to solve my problem?
12.	What is the throughput needed to solve my problem?
13.	What is the most common use case of the solution I'm developing?
14.	What are the most common actual real-life values I am manipulating?
15.	What are the acceptable ranges of the values I am manipulating?
16.	What happens when data outside this range enters the system?
17.	What does the input data looks like?
18.	What is the frequency of change of the actual real-life values I am manipulating?
19.	Where is the documentation of the tools I most commonly use to solve this problem?
20.	What is the slowest part of the system's workflow for my users?
21.	What information of my system do users need to make effective use of the solution?
22.	Which hardware is this solution designed for?
23.	How does this hardware affect the design of my system?
24.	How does my solution perform? How long does it take?
25.	How can I optimize my solution?
26.	How can I debug live release builds of my solution?
27.	Which data does the solution read and where does it come from?
28.	How often do I read data I do not need as part of my solution?
29.	Which data am I writing and where is it used?
30.	How often do I write data I do not need as part of my solution?
31.	How is the data articulated in memory?

And, remember, your project is not future proof nor platform independent! Don't forget to sit and watch actual users of your system to understand the pain points and how they interact with it.

Choosing the right technology

Yves Gurcan — Mon, 04 May 2020 17:57:06 +0000

From the user perspective, the programming language you are using to build your website does not make much of a difference. Provided that your code compiles down to HTML, CSS, and JavaScript, your users don’t care or even know if you’re using Wordpress, .NET, or React. However, from a developer perspective, the technology you chose is everything. A web developer who is familiar with PHP will have an easier time working on your Wordpress site. A software engineer with 10 years of experience with Microsoft technologies will be in his element with a .NET application. And a programmer who rocks with JavaScript will be more comfortable when you ask them to add features to your React website.

Even worse, having a developer who knows the programming language at the core of your website does not mean that working on it will be a piece of cake for them. Vue, React, and Angular are well-known JavaScript frameworks. A developer who knows one of them will already have the right mindset and understanding of the principles that govern these frameworks. Nonetheless, the implementation details are different between these three, and not all knowledge is transferable. As a consequence, it is crucial to recruit developers who are specialized in your technology stack, not just web development in general.

It is even more important to make sure that you choose that tech stack very carefully. Developers tend to enjoy experimenting with new technologies. This is fundamentally a great thing as it is beneficial in many ways. One of the advantages of experimenting with technologies is that developers stay ahead of best practices and find tools that make their job easier. However, the decision to adopt a new framework must be reasoned in order to be sustainable. Before going all-in with a new shiny library or language, make sure that your developers can answer these questions very clearly:

What is the current state of this technology? How stable is it? Be careful with alpha versions, as your developers might have to go through a lot of pain just to make it work. Is the technology documented? If not, this is a red flag, as it will prevent you to train new developers to learn how to use it.
Is there a community around this technology? The more people use it, the more likely this technology is going to stick around for years.
What are the advantages and disadvantages of adopting this technology? The perfect language or framework does not exist. Make sure that your developers have looked into the possible shortcomings of this library.
Does this technology fit your needs? Something new does not mean that it is better for you. Make sure that adopting a new paradigm makes sense for you.
How well does this technology play with your current tech stack? Some technologies are easier to mix-and-match than others. The follow-up question is: How can you gradually replace old code with this new tech?

Keeping all the questions in mind while assessing a new framework will greatly help you make the right choice. With clear answers, you will avoid adopting technologies that will be forgotten in a few years and make it easier for you to find developers who know the tech in the future. It might also help you avoid creating Frankenstein stacks which are made of technologies that don’t work together very well.

Think responsive with flexbox

Yves Gurcan — Sat, 02 May 2020 17:54:15 +0000

Now more than ever, building a website that follows the guidelines of responsive design is critical. With the variety of electronic devices on the market, having a website that looks good on all screens will help you reach more users. Writing hacks in your code to detect if your user is browsing with an iPhone or an Android is simply not enough!

Thankfully, having a responsive website is not the Herculean task that it might seem in the first place. One of the keys is to create your website with a mobile-first mindset from the get-go. Implementing responsiveness in the middle of the development cycle might cost you a lot more work. Your software engineers will more than likely end up re-writing code that they pushed recently.

So, what does it take to develop a responsive website? Knowing CSS and its subtrlties is a vital skill for this purpose! It is common to say that developers don’t like this programming language. CSS has weaknesses, for sure, but its evolution and the great libraries such as SASS and Styled Components have changed everything. Also, using Flexbox layout is going to make your life so much easier! One of the concepts behind Flexbox is that you don’t need to specify anymore the size of your elements on the page. Instead, just like with CSS Grids, you describe the layout you wish your view to adopt.

This focus on the layout of the page rather than the size of the different “boxes” is exactly what we are looking for when it comes to responsive design. No matter the resolution of your user’s screen, a well-used Flexbox will guarantee that it will look good for them, even if the aspect ratio is completely unorthodox. Of course, you can also use what is called media queries to implement breakpoints. That way, you can simply dictate the layout of your page based on the width and height of your user’s screen. Typically, you offer 3 different layouts for your application: one that looks good on smartphones, one for tablets, and one for large screens. Unfortunately, with the release of new devices with bigger screens, this approach is not scalable as you will have to constantly update where these breakpoints are. That’s where Flexbox shines. It has this little extra thing that can not be achieved by media queries: It shrinks or extends the dimensions of an element based on the size of its neighbours. And that’s how your website can look good on any screen!

However, if your developers started styling your website by hardcoding sizes in pixels, existing views are not going to play well with Flexbox, which works better when it has the freedom to decide how big or small everything on the page should be to fit in the layout you want. That’s why responsive design must be thought out before you start creating your first pages. And once you have established a framework for your views, styling will be a breeze! You’ll see!

User experience is everything

Yves Gurcan — Wed, 29 Apr 2020 04:13:36 +0000

With time, it’s natural to forget that a web application means nothing without users. Development might focus on cosmetic changes or swapping technologies under the hood. However, without any substantial improvement for your users, the value of changing the layout of your website or breaking down a monolithic application is questionable. Even worse, your paying customers might get frustrated when they notice that you are just moving things around. This bug they put up with every time they use your website is still there and nothing has been done about it. This example is simplistic, yet it is drawn from my professional experience, where I’ve seen companies rebranding themselves so often that employees themselves grew tired of it.

A good way to circumvent the problem of development work for the sake of it is to constantly ask ourselves: How does this make the user’s life easier? Similarly, when your developers add a feature to your application, the question to keep in mind should be the following: How can I help users accomplish this task in two clicks instead of three? Providing feedback to our customers is essential to a good user experience: If an error occurred, do they get a notification, even vague, that something went wrong? Or are they confronted to a spinner that will never go away? For reasons that I have yet to understand, developers seem to put these problematics on the back burner. Unfortunately, not communicating to users when things are not going as planned is the best way to alienate them and jeopardize your business.

Creating a beautiful and efficient interface is critical to the popularity of your product. Don’t underestimate the power of a polished web page! If it looks beautiful and it’s simple, you will have an easier time conquering the hearts of minds of your users.

Maintaining your website

Yves Gurcan — Sun, 05 Apr 2020 17:56:52 +0000

Once a website is ready and online, it might be tempting to simply let it be. The website serves its purpose and is updated from time to time. Nice and easy.

However, the problem of a website is that it can not be left alone once it’s online. Why? Well, unfortunately, there are people on the internet who spend a lot of time and resources to find vulnerabilities and exploit them. No website is perfectly safe and it’s a matter of time before a weakness becomes public. Once an entryway is found into your website, then all your sensitive data is exposed.

Customer email addresses, purchases, and other personally identifiable information (PII)… Once a hacker has found their way in, they will not stop at your website. The data might be sold on the black market and used to create bank accounts or make online purchases, making your customers vulnerable to identity theft.

So, when you update your website, you’re not just doing housekeeping. You’re helping protecting your customers!

Remember and ?
Yves Gurcan — Tue, 28 Jan 2020 17:39:52 +0000

Do you remember the first website you wrote? Mine was a fanpage about Doom II. Yep. That was over 20 years ago.

I used an IDE called NVU when I started getting my hands dirty with HTML and CSS. I find it fascinating that this software is still around. I remember pondering about using a WYSIWYG editor or not, which is not even a question that web developers ask themselves anymore. Also, the standard for HTML tags was to write them in all caps, like `<BODY></BODY>`. It looked awful! Do you recall `<marquee>` and `<blink>`? My co-workers and I brought back memories of these silly tags the other day. Web development in the 90s was a completely different beast. How to transfer files via FTP was common knowledge. Another lost practice… probably for the best!

In the end, I feel like the only tag that truly survived the evolution of HTML and the intrusiveness of JavaScript in the DOM is `<div>`. Despite the effort to implement semantic tags, the blandness of div is what probably encourages its use everywhere. And it seems that accessibility is the primary victim of this trend. Also, nobody looks at the resulting code of rendered pages anymore (did anyone ever did? I remember obsessing about this), so who cares?

When I look at how CSS evolved, though, I see a language that remained very stable and up to date. Even better, I believe that stylesheets grew to be an even more awesome way to create beautiful, pure designs. I’ve always considered that using JPEGs instead of CSS to build the layout of a website was a huge mistake, especially before the time of high-speed internet. I remember looking at websites in the 2000s and cry a little bit inside because of the size of the assets. Of course, float and inline-block are not really a thing anymore, thank goodness. But the recent addition of flex and grid were big game changers that promoted better styling practices.

I believe that looking, even briefly, at the early decades of web development is a good reminder of how far we got in the way we create websites. JavaScript truly evolved into something that I would have not foreseen. And the disruption from jQuery to libraries such as React and Vue was huge!

Remembering these things through the lens of nostalgia is a fun exercise. However, there is no doubt that this evolution was most definitively for the better!

UtahJS 2019: Why small is better than big

Yves Gurcan — Mon, 27 Jan 2020 19:58:09 +0000

If I had to summarize UtahJS with one word, it would be “human.”

How can a conference not be human, you may ask. Well, if you have ever attended re:Invent, you might see what I mean. Don’t get me wrong. AWS conferences are awesome. The presenters are unmistakably smart, the topics are compelling, and the hype is palpable. Personally, I still can’t get over the fact that last year there were DJs scattered throughout some of the venues playing sick tunes at 9 am. But re:Invent became overwhelming with its 40,000+ attendants, thousands of sessions, and the five hotels where it takes place.

UtahJS, on the other hand, is compact. The conference occupies only a small fraction of a multiplex in the suburbs of Salt Lake City. A volunteer told me that they expected about 400 people this year. And that’s one of the reasons why I enjoyed this conference so much. People were approachable and open to talking to strangers. In fact, I met more people at UtahJS in a day than I did at re:Invent in a week. Conversations were rich and interesting, including a discussion that got very technical about parsing DNS packets, another one where we commiserated on third-party dependencies (I’m looking at you, Lab On Demand), and also one about the vitality of the tech community in Utah.

The pace of this single-day event is fairly fast. Starting at 10 am, you can choose to attend one of three simultaneous presentations every 20–30 minutes until 5 pm. But everybody was so relaxed. In fact, people are so relaxed that the organizers incentivize people to move more quickly from one theater to the other by giving away prizes right at the beginning of each talk. This small touch creates such a fun and memorable experience. Even the sponsors, who are invited to present their company in person at the beginning of the conference, ditch the dullness of marketing talk to some extent and expose themselves in a very personal, vulnerable way.

From React Suspense to imposter syndrome, the topics covered in the 2019 edition of the conference were pretty eclectic. My choices were driven by what I like to call the 3 learning phases: discovery, improvement, and confirmation. In other words, my goal was to explore concepts that were somewhat new to me (such as idempotency and resiliency), improve in domains where I knew I could easily progress (namely, code reviews and algorithms), and reinforce knowledge that I acquired from previous experiments (e.g., web sockets and designing vanilla JavaScript applications). Since the talks are so short, don’t expect to go deep into a particular question. However, I got very clear takeaways from each speaker, with ideas and tools to explore at my leisure.

To put it in a nutshell, I think that UtahJS is a great conference which shows a lot of humility. The atmosphere was playful and respectful. Even if the pace was somewhat fast, I wasn’t overloaded with information. At the end of the day, I had discovered new perspectives that will undoubtedly contribute to the improvement of my skills as a software engineer. What else can you ask for?