DEV Community: Rene Pot

Your New Year’s Resolution: You don’t need a GitHub contributions streak

Rene Pot — Mon, 01 Jan 2024 15:04:16 +0000

It’s time for a New Year’s Resolution, don’t fall into the trap that you need to have a contribution chart that has every day colored. Instead, focus on your mental health!

For many years I’ve seen people compliment GitHub profiles that have every day colored on their contribution chart. Those people, in turn, proudly post a screenshot of their contributions on Social Media to show off.

Mitchell Hashimoto’s GitHub profile (tweet)

However, while this does indeed look awesome, and it might work for serial-entrepreneurs like Mitchell (founder of Hashicorp) and maybe for you, this shouldn’t be something to look up to necessarily.

One of the good things in this chart, is there are gaps. Way too few if you ask me, but they exist. To me, this highlights that there aren’t any vacations or weekends off. Not a single weekend was spent offline entirely, and not a single week was spent not working.

I totally get it though, I too have 100s of projects queuing in my head for attention, and I’d love to be programming all the time. But having time off, is really important.

I’m calling out Mitchell here specifically because I noticed his post on Twitter, and because he has quite a following. I’m not saying it is bad to have a profile like this, all I want to focus on is that you don’t have to have a profile like this to be noteworthy. It isn’t a must have nor a goal you should strive for. However, if you might end up with a full chart accidentally, it could also mean you just really enjoy your work.

What should it look like?

So what should your GitHub contributions chart look like? That’s actually quite easy. As full or empty as you’d like, but make sure your mental health is coming first! If you’re perfectly fine with working every day, then it’s also fine to have a chart completely filled. No matter what you choose, your own sanity should come first.

This is my chart, and I’m very happy with it! Though I would’ve wanted to work more, this is what made sense to me.

But never ever start contributing or working when you don’t feel like working that day. It’s absolutely fine to have a day, weekend, week or month off from GitHub. Take the time you need, and don’t contribute for the sake of contributing.

In the end, the quality of your contributions matters, not the quantity. Not everyone can produce high-quality contributions at a high pace. For example, Vermeer produced only 34 works while Picasso produced over 100.000. Both produced high quality, but I’m sure if Vermeer would’ve tried to make 100.000 pieces, the quality wouldn’t have been very good.

One thing is for sure, if I see a completely full chart on GitHub, I’ll always wonder if they’re okay and if they’re taking enough time off. If you ever sit across from me at a job interview, I’ll be asking that exact question; “Are you taking care of yourself above work?”

Happy New Year, enjoy 2024, and put yourself (and your health) before work!

Using ChatGPT for productivity in JavaScript: Quick wins

Rene Pot — Wed, 29 Mar 2023 13:46:07 +0000

If you’ve been anywhere on the internet in the past few months, you’ve seen AI plastered all around. There’s no escaping it. And there’s a good reason for this. It’s actually quite revolutionary when it comes to usefulness and productivity. But now it’s time to integrate AI into your work, and I’m here to tell you how.

There are a few tools out there that are useful to you as a software developer, but for now, let’s look at ChatGPT. There’s also GitHub Copilot, which can do similar things as discussed below but works slightly different, so that’ll have to wait for the next blog post.

All of the examples below are generated using ChatGPT-4, which is not yet available for everyone. The current ChatGPT model available to everyone is GPT3.5, so keep that in mind.

General warning: ChatGPT can generate incorrect or very unoptimized code (or both), validate your responses, and understand what it’s doing. Sometimes even asking ChatGPT to optimize or fix the code it just provided will generate better results as well.

Extracting Styling

ChatGPT is a language model, but it can do conversion extremely well. Take a React component that has inline styling. This is ugly and typically not recommended. This is some of the styling I got.

const defaultStyle = {
    display: 'inline-block',
    borderRadius: '8px',
    padding: '10px',
    background: 'linear-gradient(to bottom, white, lightgrey)',
    boxShadow: '0 4px 6px rgba(0, 0, 0, 0.1)',
    transition: 'all 0.3s ease',
  };

But this is something I would prefer to see in CSS and a module.css file at that. You can very easily paste your entire react component to ChatGPT and ask:

Can you convert this styling to be in a module.css file

It will generate the css for you:

.roundedBox {
  display: inline-block;
  border-radius: 8px;
  padding: 10px;
  background: linear-gradient(to bottom, white, lightgrey);
  box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);
  transition: all 0.3s ease;
}

And then it’ll tell you how to import, and apply the style.

import styles from './RoundedBox.module.css';
// [ more code ]
<div className={styles.roundedBox} {...props}>

There are some tweaks you can make and some suggestions you might not use. But… the conversion is correct and working.

Generating helper functions

Sometimes there are little things you need doing, that are specific to your application. You can use ChatGPT to create this helper function for you by specifying the input and the output, and then tell them what kind of code it needs to generate.

You can also provide the test as the input and ask ChatGPT to write a function that works on the test, as a Test Driven Development kinda way. But for now I’m not going to do this.

This was my input to generate the function.

I need to convert a string to a list of words and their count, 
and the array need to be structured like this:
 [{“word”: “myword”, “count”: 5}]
It needs to be in JavaScript and needs to be short and concise, and readable

And then I got this as a return value

function countWords(str) {
  const words = str.split(/\\s+/);
  const wordCount = {};
  words.forEach(word => {
    wordCount[word] = (wordCount[word] || 0) + 1;
  });
  return Object.entries(wordCount).map(([word, count]) => ({
    word,
    count
  }));
}
const inputString = "example string with words and words and example";
const result = countWords(inputString);
console.log(result);

It even outputted the result for me, which was a nice bonus. It might not be entirely optimized or follow the guidelines you’d like to follow, but it generates code that actually works and does what you need it to.

Writing tests

Yes, it’s not Test Driven Development, but I asked ChatGPT to generate a test based on the function above using Jest. It even gave me instructions how to install Jest, how to add it to my project and how to name my test file. And the test it came up with was:

// countWords.test.js
const countWords = require('./countWords');
test('Counts words in a string', () => {
  const inputString = "example string with words and words and example";
  const expectedResult = [
    { word: 'example', count: 2 },
    { word: 'string', count: 1 },
    { word: 'with', count: 1 },
    { word: 'words', count: 2 },
    { word: 'and', count: 2 }
  ];
  expect(countWords(inputString)).toEqual(expectedResult);
});

I followed the Jest installation instructions from ChatGPT, and behold; my test ran successfully.

PASS  ./test.test.js
  ✓ Counts words in a string (1 ms)
Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.171 s, estimated 1 s
Ran all test suites.

To loop back on the “Generating helper functions” section above, I pasted this test to ChatGPT in a different thread and asked it to write a function for me, and it provided me with pretty much the same code as the one generated there.

Writing JSDoc

Very straightforward, but something very useful as well. ChatGPT can write JSDoc for any function you give it. Just provide the code, provide the request you need JSDoc, and you’ll get something like this:

/**
 * Takes a string and returns an array of objects containing each unique word
 * and its count within the string. The output array has objects with the
 * structure: { "word": "example", "count": 2 }.
 *
 * @param {string} str - The input string to process.
 * @returns {Array.<{word: string, count: number}>} An array of objects, each
 *   containing a unique word and its count in the input string.
 */
function countWords(str) {

This can be incredibly useful for making documentation, adding auto-completion, and adding readability. Especially if you work with multiple people on a team.

Convert JS to TS

Yes, you can use ChatGPT to convert JavaScript files into TypeScript. Though I will state once again, make sure to validate the response. It can return incorrect conversions or just make mistakes. However, I’ll show you the TypeScript I got generated from ChatGPT, which still works as expected.

// countWords.ts
interface WordCount {
  word: string;
  count: number;
}

function countWords(str: string): WordCount[] {
  const words = str.split(/\\s+/);
  const wordCount: Record<string, number> = {};
  words.forEach((word) => {
    wordCount[word] = (wordCount[word] || 0) + 1;
  });
  return Object.entries(wordCount).map(([word, count]) => ({
    word,
    count,
  }));
}
export default countWords;

Conclusions

So now that you see what ChatGPT can generate for you, you can imagine the time you can save by letting ChatGPT do some of the work for you. However, it’s not something you can just copy-paste and be done with it, like you’ve always done with StackOverflow. You need to ensure you understand what is returned, if the returned value is the best way to do something, and if it didn’t introduce any bugs or incorrectness into your code. Maybe it assigned the wrong type when I converted to TypeScript, maybe it misses edge cases when generating tests, and maybe it has wrong texts in the JSDoc it has generated.

Your go-to flow should be:

Request what you need from ChatGPT.
Validate that what is generated is actually solving your request.
Validate the code against manual/automated testing.
Walk through the code to make sure it’s up-to-date, follows best practices, is optimized, and doesn’t do things it should absolutely not do

In general, once you get to work with ChatGPT more, you’ll learn to spot where it can make mistakes, and what it’s good in. I never validate converted CSS for example, but I do test TypeScript conversion and JavaScript functions myself.

How You Can Use AI to Improve Your Programming Skills

Rene Pot — Wed, 01 Feb 2023 08:27:16 +0000

I’ve seen a lot of people write about AI, and how it will disrupt everything. While it is true it’s truly amazing, it’s not there yet. Tools like GitHub Copilot and ChatGPT are most frequently mentioned, but how can you leverage them to your benefit?

So let’s get this out of the way first. AI is not here to replace programmers. It never will. knocks on wood. However, it is there to make the programmers life easier. But first a look back a few years.

I’ve been in software development, professionally, since 2008, and as a side-gig a few years before that. So I could say I’ve seen some earlier transitions. In 2008 there were no frontend frameworks like we know today. jQuery came out in 2006, and that was one of the few popular ones. And UI libraries, like Backbone, started releasing around 2010.

The framework landscape was very different. And with the advent of massive time-saving frameworks like React and Angular, came the fear it would reduce the workload enough people would be fired. But look at us now, even with the massive amounts of layoffs happening everywhere, there still is a shortage of developers.

Take it back further a few years, when I was still in high school and exploring what to do after, I landed on “Communication and Multimedia design” with the intention of improving my programming skill-set and get some extra knowledge in related activities such as av-design and 3d modeling. But while exploring I noticed a trend, everyone recommended not to go in the field of programming, as it was predicted there would be a surplus of developers as we’d reached the peak. Considering this was 2005, only a few years after the dotcom bubble, I could imagine people being afraid of this “Web2.0”, but it turned out alright for everyone.

Anyways, back to 2023. AI is here, we’ve got AI like ChatGPT and GitHub Copilot for text-based AI, there’s DALL-E and Midjourney for images, Microsoft can replicate your voice, Apple has AI narrated books, and the list goes on. It all seemed to be coming from nowhere and now everyone is talking about it.

And with the talking, comes the fear to be made redundant. And I think this is not something we’ll see in the near future. If anything, it will make us more optimized, which means, we can collectively do more work. And with more work, more inspiration, and the ability to produce more faster, comes more inventions, more ideas and more demand for programming.

If you’re currently working at a company as a programmer (or related position) you probably know your list of tickets is longer than you (and your team) can ever complete. This is some sort of paradox that just keeps on going, even after a massive cleanup. Maybe you could get a little more done with the use of AI.

And of course, this might pave the way for one-man “teams” who can do things previously not possible to do alone, and this might be a new era of startups changing the internet, again. But I guess that is the optimist in me talking.

Using AI to improve your programming

Alright, you read my rambling about AI and an optimistic view, but not yet where you can here for. How can you use AI to improve your programming.

I’ve seen people use the result of AI’s directly, and while this may work, this isn’t improving your work, this is the equivalent of copy/pasting a StackOverflow answer. Sure, you could, maybe, write a simple back-end in a language you’re not familiar with ,or you could convert comments and variable names to a language you don’t speak, but none of that is actually productive.

Don’t do this though, don’t blindly copy-paste anything from ChatGPT without knowing what it does, and if it even works/does what you ask it to.

using System;
using System.Security.Cryptography;

public class ConvertidorISO
{
    public static int ConvertirANumeroAleatorio(string fechaHoraISO)
    {
        // Convertir la fechaHoraISO a un arreglo de bytes
        byte[] datos = System.Text.Encoding.ASCII.GetBytes(fechaHoraISO);
        // Utilizar el algoritmo SHA256 para crear un hash de la fechaHoraISO
        byte[] hash = new SHA256Managed().ComputeHash(datos);
        // Convertir el hash a un entero y devolverlo
        int numeroAleatorio = BitConverter.ToInt32(hash, 0);
        return numeroAleatorio;
    }
}

The above is the code it gave me when I asked it to write a function in C# to convert a ISO timestamp to a random number, in Spanish. I don’t speak Spanish, and I’ve never programmed in C#, so the methods it’s calling are unknown to me, and I don’t know if they exist or do what ChatGPT tells me they do. So if one of the readers can confirm this code works that would be great. After this prompt ChatGPT also started just talking Spanish to me, so I guess it suddenly thought I was Spanish. And furthermore, I doubt it actually does what I told it to do.

This however is a prime example why you should not just blindly copy/paste code an AI gives you, you need to actually know it works, and does what it says it does. ChatGPT can confidently lie, and sometimes even back it up with sources (which don’t confirm the lie at all). Though often it seems I get code that, at least, mostly works. So I can semi-confidently say the code above should, probably, work.

However, imagine this scenario. You’re working on a ReactJS application, and you want to get some inspiration/help from an AI. What you could do is let it help you, instead of doing the work for you.

I recently wanted to make a background of a React Application black with randomized stars scattered around the screen, to give the illusion of being “in space”. I could’ve written it myself, no problem there, but I didn’t feel like figuring out colors to use, Unicode characters to pick and what that CSS was again for absolute positioning and screen-dependent font-sizes, so I asked ChatGPT: “Can you give me an array of realistic colors suitable for stars”. It did, it gave me about 10 colors in yellowish and whiteish tints. I asked it to add some blueish and orangeish colors, and it came up with a complete array of nice colors.

["#F5A623","#F39C12","#F1C40F","#F7DC6F","#FDEBD0","#F5B041","#F8C471","#F9E79F","#F4D03F","#F7DC6F","#F2C94D","#F08080","#F28482","#F1948A","#F5A4A9","#F8B1B3","#F7C6C7","#F9D9D9","#F2E6E6","#F2E8E8","#F7CECE","#f7f7f7","#d9e6f2","#d0e0f4","#c4e6f4","#c2e0f4","#c1d9f2","#c2c8e6","#f7f7f7","#f7f8fb"]

But note, I didn’t get this array presented to me like this, it wrote some code around it, and since then I’ve put it in my own repository and my formatter put every color on a new line. And while this is nice, it doesn’t work well in an article, so I, just now, asked ChatGPT to minify it for me, and so it did.

You also might notice, if you scrolled in the array above, it started using lowercase characters for the colors instead of uppercase in the first 20 or so. Of course one request to ChatGPT can fix that.

This is one of the strengths of using ChatGPT, you can ask it to do something very specific, and it’ll do it happily.

So what about those Unicode characters you ask? Well this is what it came up with, which I like a lot.

const stars = ["★", "✶", "✴", "✵", "✪", "❂", "⚜", "⚘", "⚚", "⚛", "⚙"];

Then came the next question I asked ChatGPT: “can you create a randomized amount of stars on a randomized position on the screen”

And one of the snippets of the code it gave me was this:

const [starData, setStarData] = useState([]);
    useEffect(() => {
        setStarData(generateStars(Math.floor(Math.random() * 50) + 50));
    }, []);

The generateStars function looks like this:

function generateStars(n) {
    return Array.from({ length: n }, () => {
        return {
            character: stars[Math.floor(Math.random() * stars.length)],
            left: `${getRandomNumber()}%`,
            top: `${getRandomNumber()}%`,
        };
    });
}

This is not a piece of code I would’ve come up with. I probably would’ve classically done a for loop, but I dig this response and it looks like a smart solution. For the purpose demonstrating the viability of using ChatGPT I actually used this function, where I would probably have written this myself in any other case. But it shows AI can generate code that’s very usable.

But, in the process of getting this code, it initially wrote styling right in the code, didn’t use absolute positioning at first, and the style it did generate was not the kind I’d like to see.

But here’s the key, I knew what I was doing, I wasn’t going in blindly. I had never used the Array.from method before, so it let me learn about a new Array method and how to use it, and in the end the result it gave me was tweaked to make it more readable and structured.

While making it more readable, I wanted to strip away css-in-js. I wanted it back in the css files, as I like my code clean. So I copied the styles JavaScript object it had generated previously (and I had tweaked after to make it do what I wanted to do), pasted it to ChatGPT and asked it to convert it to CSS. It did, and it worked perfectly. It even told me what it had changed, so again, I learned in the process. Of course, after the conversion I validated it had actually converted every property, and made sure they all worked as expected.

So how does this help me?
Well that should be quite clear, you can ask it to do specific things you know how to do or have a an idea in the general direction, and validate the response. It would’ve taken me quite some time to come up with the 30 colors it generated. And scrolling through a list of Unicode characters would have been time intensive too, so that helped.

Remember how I told you it can lie confidently?

I just asked ChatGPT, for the paragraph above, how many items there were in the array. And it flat out told me, “There are 42 items in the array.”

Which, isn’t true. So this is how the conversation went. Of course I had to make a joke first.

It apologized it was wrong, and then it gave 43 as the answer. Pestering it again it was wrong again, it replied with 45. Not sure what is up with that, but it clearly wasn’t counting my array. Right after that it started error-ing out for me, so maybe I broke it in the process. If it went down just now, I’m sorry, it broke on 42. Ironic?

But there’s more than just ChatGPT

So let’s continue, there’s indeed more than just ChatGPT. I’ve been also experimenting with GitHub Copilot. And no, this section is not sponsored by GitHub (I wish, hah), I’m still in the 60-day trial, and most likely will pay after it ends, as it really helps me.

As you might see in the code provided above, I didn’t actually include the color for the stars. This is because my original prompt to ChatGPT was just for random stars, not colored stars. This is also key with working with AI, you will have to give it specific prompts, so you know they’re actually giving you responses you can work with. The more complex the prompt, the bigger the chance you’ll get a broken result.

But yeah, moving on from ChatGPT. I used GitHub Copilot to help me implement the colors. I pasted the array of colors in my file.

const  starColors = ["#","#"]

And then I went to this code:

const style = {
    left: star.left,
    top: star.top
};

I typed a , after the top: star.top line, and it automatically auto-completed with this:

color: starColors[Math.floor(Math.random() * starColors.length)],

I hadn’t asked it anything, no comments, no suggestion, only the fact I pasted the colors array on top did the trick. Perhaps it looked into the name of the array or the properties within the style object, but nonetheless, I hadn’t had to write that line. I didn’t even write color: to get it autocompleted correctly.

And that line is exactly what I wanted to achieve. I knew what I wanted, I was already going in to write exactly that line, and it fixed it for me. This being at 11pm, I might’ve even forgotten about Math.floor and used Math.round instead. For some reason a mistake I regularly make, but that might be because I don’t often get random items from arrays, especially considering I’m a Developer Advocate for my day-job, I program less than I’d like.

So how did it help me in the end? I spent just 10 seconds implementing the color style, where I would’ve spent 30–60 seconds on it normally, plus I might’ve hit a small bug that would’ve caused me to spend another few minutes on it figuring out why my code was wrong in the first place. In the end, this one saved me time!

And those improvements, cutting 30–60 seconds down to 10, doesn’t seem like much. But if it happens 10 times in an hour, you saved yourself up-to 10 minutes already. And that’s a low estimate based on my experience, usually I get these kind of suggestions constantly and probably get close to double my productivity.

So how can I learn?

Well one the methods you could use, is Rubber Ducking. A method of debugging code.

I, on purpose, created an error in a JSX snippet, and I asked it what was wrong. And it quickly spotted my mistake. Of course I could’ve quickly spotted this myself by just trying to run the code. Or my IDE could point it out (it did), but this is a matter of demonstration.

Let’s take a look at an earlier mistake I pointed out, using Math.round instead of Math.floor. Would it be able to spot the mistake itself?

Funnily, it actually said it couldn’t be because of Math.round. Yet another example why ChatGPT lies. Questioning it further it actually did give me the right answer, which is all what Rubber Ducking is actually about. You need to dumb things down enough, step by step, to get to the problem. It’s not called Senior Devving for a reason, a Rubber Duck will never answer your questions, as it cannot speak (I hope).

So by dumbing things down, you’ll get to the answer. Don’t assume ChatGPT will solve your problem, but it can be a second person you can voice your frustrations to.

Explain my code

ChatGPT can explain your code for you, even if it is minified. I took the generateStars() function I spoke about earlier, and let ChatGPT codegolf it for me, it made this mess:

g=(n)=>Array.from({length:n},()=>({c:stars[Math.floor(Math.random()*stars.length)],l:`${getRandomNumber()}%`,t:`${getRandomNumber()}%`}))

Now, this code suddenly is a mess, and it’s quite difficult to find out what it does, but ChatGPT comes with the solution. I pasted this code, and asked it to explain it for me, and it came up with this:

The function uses `Array.from()` to create a new array with length
"n". The second argument to `Array.from` is a function that creates an
object for each element in the array.

The object has properties "c", "l", and "t" with values assigned as:

- "c" is assigned a random value from "stars" array.
- "l" is assigned a string of random number + "%" sign.
- "t" is assigned a string of random number + "%" sign.

The function creates an array of objects with random values. The
function call `getRandomNumber()` is not defined, it could be a user
defined function.

As you can see, it’s capable of understanding the code quite well, and even if it missed a few details and cannot understand context, it could help you understand the code. You can also do this with the code your coworker produces that no one understands.

From here it can actually de-minify the code as well, in case you want a nicer read.

function generateArray(n) {
  return Array.from({ length: n }, () => {
    const c = stars[Math.floor(Math.random() * stars.length)];
    const l = `${getRandomNumber()}%`;
    const t = `${getRandomNumber()}%`;

    return { c, l, t };
  });
}

Learning from Github Copilot

So then there’s Copilot. And you can learn from it too! But most importantly, it will help you write comments!

Let’s say you’re going to write a function that will generate a random number between a min and a max. Oh fun fact, that was actually how the code came to be, the one I purposefully changed from Math.floor to Math.round. I generated this code by writing a comment first.

// This function takes in a min and max value and returns a random number between the two

And then, without any further prompts, it autocompleted the code I wanted to have.

And while the comment here is a bad example, because comments should explain the why, not the what (as that should be self-evident), it still demonstrates the ability of Copilot to generate code with a commented instruction.

Writing JSDoc

CoPilot is very capable of writing JSDoc comments above methods. As an example, which ties into my “stars” background from earlier, I have a function that generates a random asteroid with random composition based on a pre-defined array. My code is very simple:

function generateAsteroidComposition(amountOfMaterials) {
    const mats = [...MATERIALS];
    let pickedMaterials = pickMaterials(mats, amountOfMaterials);
    return pickedMaterials;
}

I added the JSDoc code above it

/**
 * 
 */

And after typing a space after the 2nd row * , GitHub Copilot suggested the following:

/**
 * Generates a random asteroid composition based on the materials array
 * @param {number} amountOfMaterials - The amount of materials to pick
 * @returns {array} - An array of materials
 */

As you can see, Copilot dove into the pickMaterials function to determine the logic and the return value, and knows what the generateAsteroidComposition does.

When doing the same with the pickMaterials function, which I haven’t shown you, it gives me this JSDoc, including an example!

/**
 * Picks materials from the materials array
 * @param {array} materials - The materials array
 * @param {number} count - The amount of materials to pick
 * @returns {array} - An array of materials
 * @example
 * // returns [{name: "iron", probability: 15, value: 0.15, weight: 100}]
 * pickMaterials([{name: "iron", probability: 15, value: 0.15}], 1)
 */

It’s not 100% correct, as the return doesn’t have the "value" property, but that’s the only thing I can complain about, as it does the job perfectly otherwise. Would you have done this with code you do not know, it would most certainly given you insights into what the code does, and it would add documentation to the code, you only need to validate manually after.

Conclusion

AI is great, really. It can help cut down effort to write code, it can be a rubber duck, it can autocomplete code you didn’t even know worked, and it can give you ideas how to solve problems you had no idea how to tackle.

But there’s a caveat, it can lie, confidently. Take every answer with a grain of salt, and confirm every answer it gives you by validating the code and solutions.

Overall, AI is mostly a performance-increasing tool. You still have to know programming and have the programming mindset to use AI to code. It hasn’t replaced programming, it will make it easier. Just like it’s easier to write in languages such as JavaScript and C# as opposed to binary.

Furthermore, this article was written at the time ChatGPT was in the January 9th version and free. Rumors go around it will cost $42/month after it will go paid. That amount might seem like a lot, but if you are freelancing as a software developer, you most likely charge twice that amount, per hour. This tool will save you 30 minutes a month easily ,so it is absolutely worth it. Just like the $10/month or $100/year for GitHub Copilot.

Titanium is alive and well!

Rene Pot — Wed, 13 Jul 2022 08:36:30 +0000

Yeah, that's right. The amazing, and my favorite, native cross-platform Mobile Framework is still alive! It recently even received a new massive update!

But before I dive into that, let me tell you my history with the JavaScript SDK.

Between 2011 and early 2021 I was heavily involved in the Titanium community. At first mostly as a user, but only a few years after I've first started using it I attended meetups, and later started hosting meetups, founded the Titanium Slack community, and then became a Developer Evangelist at Axway Appcelerator, the company in charge of building the Titanium SDK. Unfortunately early 2021 Axway announced they were going to discontinue Titanium, and by extension, hand it over to the community. As a person in Developer Relations, the moment that announcement was made, my job ended. So I had to move on.

So those of you who paid attention to the timeline might wonder, wait, did you really start using Titanum in 2011? Then I say, yes! Titanium was, next to Phonegap, the only cross-platform framework out there for JavaScript, and it didn't rely on web! So yes, it predates Xamarin, React Native, NativeScript and obviously Flutter. It even predates NodeJS which it heavily relies on nowadays for building. And while that is only about 11 years ago, pretty much any framework or SDK we use now didn't exist back then. The web was mostly jQuery at that point.

But we're getting offtopic here. Titanium is alive, had I mentioned that yet? It's pretty amazing if you think about it. The 11th major release came out only recently. It's the first major release since TiDev took over the development and maintenance of Titanium.

So what's TiDev? TiDev is a community driven and funded non-profit that maintains and updates Titanium and all it's related technologies. They have all their software, open-source, on Github and thanks to the help of the community they get funding through, mostly, Github Sponsors.

I'm incredibly happy the team behind TiDev managed to get an update out there, and I cannot wait what will happen next. I'm already looking forward to the update that will support the next version of iOS, and I'm sure many of the community do the same.

And in case you're not a Titanium user and you made it this far in the blogpost, can I ask you to chip in as well? Let's make the cross-platform ecosystem a little more diverse by helping Titanium get more popular again! Check out the website, and try it out, and if you like it, perhaps sponsor them on Github as well!

Oh, and if you're tired of building mobile apps in React Native, maybe this is the platform for you!

The importance of good Documentation

Rene Pot — Sat, 28 May 2022 10:34:23 +0000

We all know documentation is an important part of any software. Whether that is through self-documenting code or hosted documentation on dedicated websites. In the end, all that matters is the quality of the documentation.

I've been in software development for most of my life, and so consuming documentation, tutorials, guides or otherwise, has been part of most of my life because of that.

Over the years I've dealt with everything from completely missing documentation to the most complete and comprehensive documentation imaginable. And of course everything in-between.

The most common form of documentation, however, is within the files I'm dealing with. In the end, as a software developer, most software I'm dealing with has been written by the team I'm involved in, and usually no disconnected documentation is written. In the end, this typically means two things. Software without comments, or software with comments.

In the past, I've written about self-documenting code and its importance. And I still stand by this fact. When dealing with software development teams, there's no way there's time for maintaining proper documentation. Practicing the routine of having well-named functions, variables, and filenames is easier than having to explain in your code what everything does.

And this brings me to the opinion that documentation has to be either good or non-existent. If you have a different view on this, I'd love to discuss this with you. It's always interesting to hear different approaches, and I'd love to be proven wrong!

Whenever you, or anyone in your team, decides to write external documentation, you (or your team) will have to continuously put in the effort to maintain this documentation. Make it part of the routine to update whenever relevant products or tools get updated, and whenever you estimate anything related to these tools, also estimate the time it takes to update the documentation accordingly.

And here's why; As soon as the documentation is slightly outdated or incomplete, those reading the documentation can assume two things. Either the documentation is outdated and they'll have to figure things out for themselves, or they've discovered a feature that might, or might not, be not intended to be used.

When you encounter undocumented features, you'll need to ask yourself if you want to use this feature. There can be consequences of using them, and I think most people in software development have had to deal with this. Often undocumented features can be broken in future versions. Either intentional or unintentional. There's a big chance they're undocumented for a reason. They might be pending deletion once the final piece of software using it is rewritten, or they might not be feature complete yet and have breaking changes in the near future.

In any case, once you find undocumented features you need to do your own research. When it's software written by the same team, you can simply ask the person who wrote it (Thanks git blame!) and get your answers. But if the software is from a 3rd-party, you can either never know the answer, or you'll have to raise a ticket and hope for a proper, and timely, response.

And this is exactly why documentation needs to be up-to-date, or non-existent in the first place. If there was no documentation at all, and the software was simply self-documenting, you wouldn't have to worry about any of this. But if any documentation contradicts the actual software, you can get down to endlessly researching what part is the supposed truth. Is it a bug? Is it an undocumented feature? Is it an accidental commit that slipped through code review? Or is it simply a forgotten piece of software that should've been documented in the first place, but there was no attention given to it.

All I'm trying to say, is to make sure you consider what you document and schedule time for maintenance every time the software is changed!

And this doesn't just apply to your (or your team's) codebase, but also to SaaS and other software where the user doesn't touch any code at all. If you document something, document it well, or omit it completely. Humans are remarkably capable of figuring out things for themselves, but if they're told to do things according to specification and it doesn't work as expected, you raise questions.

In the past 4 years I've worked as a Developer Advocate for several companies, and if there's one thing I've learned over the years, is that most questions come from incomplete or outdated documentation.

The number of questions I've had cross my desk about documentation that was forgotten about and completely outdated/non-functional by the time the user in question started using it, is insane. But whenever software was released undocumented the questions were mostly due to bugs in the software, not because of the lack of documentation, and those questions will be there regardless of documentation or not. And trust me, this was not due to lack of adoption.

Conclusion

So in conclusion? Well, I've already said this a few times, but it can't be repeated often enough. There are, in my opinion, only two routes you can take.

1. Omit documentation

Omit documentation en and make everything either self-documented (in case of SDK's/code files) or intuitive (in case of SaaS). In both situations here developer/user experience should be on top of your mind

2. Always update documentation accordingly

Write proper documentation, and always keep it up-to-date. Schedule time every time the SDK/product gets changed to make sure the documentation is up-to-date, and simply never let this slide. As soon as you forget to update your documentation once, it's easy to do it more frequently, and before you know it, your documentation is a dinosaur and doesn't help your users at all. It hurts adoption, productivity and maybe even your company.

How Setting Arbitrary Deadlines Can Hurt Developers

Rene Pot — Mon, 06 Dec 2021 19:20:34 +0000

A deadline on its own isn’t a bad thing — I’d even argue it might be good. Usually, I personally perform better with a deadline in mind, and just having an open-ended project can hurt the project in the long run. The key is to find the right balance and to be realistic about it.

Deadlines have to be there for a reason. Just because is not a good reason. It is a horrible deadline practice and can hurt you or your developers. Luckily, most companies I’ve worked for haven’t had issues with arbitrary deadlines, but some have. And let me illustrate a situation I encountered.

I was working at a startup, the front-end team was 3 people, and the back-end team was an equal size. We were working on a new version of the mobile app and a deadline had been set for when it was supposed to go live. However, this deadline was just thought up by the CEO/CTO and there really was no reasoning behind it.

Well, no reasoning isn’t entirely true, the deadline was set based on an estimate of the developers.

If you are a developer, or frequently work with developers, you should at this stage understand what the problem is.

Estimates are estimates, and usually wildly inaccurate. That is not because the developers are incompetent, but because it is incredibly hard to estimate a full project. There are so many aspects that can completely throw off an estimate that you never could’ve predicted.

Anyways, the prediction of the project was the result of a 2-day meeting, going from a brief of the new features, to dissecting every part thoroughly, and then cutting that up even further. Then every part was estimated, cross-estimated, referenced to UX and UI designs, and then all the hours were counted, a margin was added, and there we had our deadline.

And you might think, having UI and UX design ready and including margin in the estimate should be good enough right? That is already much more than most estimates deal with.

Well… no, it wasn’t.

The estimate was somewhere in the range of 3–4 weeks, which is pretty short for a new app release for a small team.

Of course, 2 weeks into the project, and we were behind the schedule. Not because we were slow, or didn’t put our hours in, but because things always turn out differently than expected.

The back-end was busy implementing an API for the mobile app to consume, only to figure out the system couldn’t correctly handle the simple add-on, which meant they had to rewrite a section of the existing API to accommodate for it, pushing the schedule back 2 days for the API endpoint to be done.

And because of the small rewrite, the API would work slightly differently than discussed, leading to a small, few hours’ worth rewrite of a section of the app.

These kinds of rewrites are typical for applications of any size and should surprise no one. However, the deadline was set. And now we were behind schedule.

So what did we have to do? The next day we were requested to crunch an extra four hours to get ahead of the curve again. Four hours on top of a regular working day of 8 hours. Sure, we got free food, but a 12-hour day is never good for your head. But, we managed to get on the track with the deadline again.

A week later, the app update went live. We celebrated the release, someone got some cupcakes as a treat, and then 5 minutes later everyone was behind their computers again pretending nothing happened.

This update had nothing really significant in it that it had to go live that day. Not a single user of the app even knew the update was coming, nor did anyone rely on it (investors/customers/etc). It was a nice feature alright, but would it really have hurt if the update was released a day later? Would it have impacted anyone?

But, it impacted the developers. There was internal complaining between different developers, and the relation between the developers and the higher-ups wasn’t really great.

And this wasn’t a one-off either, it happened frequently. Approximately every other month during the time I worked there.

So what would the take-away from this be? Should you just completely throw deadlines out of the window?

Well, absolutely not. As I mentioned at the beginning of this article, deadlines are usually good, and I actually thrive on them. But they should be targets, not hard deadlines. It should be okay releasing a feature a day (or two) later than estimated. Do you really want to put pressure on developers? Do you think the code quality will remain high during a crunch?

The mentality during a crunch, working extra hours on a workday evening, was, “Let’s get this thing done ASAP.” Sometimes shortcuts were taken so things would work but required refactoring later again. Sometimes these shortcuts were actually put on a schedule to rewrite, sometimes they were forgotten, sometimes the developers themselves didn’t even notice a shortcut was written just because they were tired and wanted to go home.

And when (if) they were refactored, it probably cost more time than the crunch itself. Bugs often were found later in code written during those crunches, and frustrations were high when bugs were found in the production application.

My guess, and I never really measured it so take it with a grain of salt, is any benefit from the crunch was short-term, yes the deadline was met, but the next one was delayed pre-estimation because of rewrites. Developers were less happy (and guess what, developer churn was high), and there were more frustrations overall. And then we’re not even talking about bugs that impacted users post-release.

So how should you do it?

Take your time to do things right, listen to your developers, and make sure to keep track of the progress being made. If deadlines can’t be made and they’re not urgent, postpone! Not with an arbitrary time, but with what is estimated at that point is the delay. Encourage developers to notice risks and delays and bring them to attention. If developers notice something falls outside of the expected scope, they should bring it to the attention of the Product Owner (or whoever manages the team and deadlines), and then the target release date can be adjusted accordingly.

Done ahead of schedule? Well, that is a win-win for everyone! Not only is there more time to properly do QA on the application, but you could also invite the developers to improve the existing codebase.

If you’ve ever worked with developers (or are a developer) you know there are always wishes of improving certain sections of the code. Sometimes it only takes an hour, sometimes it can span several days. Take time to improve what is there and clean things up. Because we all know there always will be messy parts in an application that no one really likes.