DEV Community: Ray

Fearless In The Face Of My Ignorance

Ray — Wed, 11 Aug 2021 06:08:50 +0000

I know so much more than I did when I started working as a software developer five years ago, but I seem to have forgotten something: How to remain fearless in the face of my ignorance.

When I started working in software development I got all the advice that we give junior devs - several small PRs are better than one big one, composition over inheritance, write your tests first (or at least concurrently) to your logic, coffee is good but adequate sleep is better. The top thing I heard? Don't be afraid to ask questions. This one puzzled me because I wasn't afraid to ask questions. I was new after all and so of course I didn't know what I was doing. Of course I would be asking a lot of questions.

Five years later and I can't in good faith call myself new at this anymore - I'm the one reminding the junior engineers to get enough sleep! I've been an Android developer for five years, adding in React Native and iOS for the past three. I am competent & comfortable with Java and Kotlin. I've grown to really love Typescript. I know enough Swift to be effective and enough Obj-C to get by. I am passionate about mobile tech and can talk your ear off about Native Modules and the React Native Bridge. But I seem to have forgotten how to remain unafraid of asking questions.

Somewhere along the way I became afraid of saying, "I need help". Somewhere along the way I started avoiding saying, "I don't know". Somehow I got it in my head that I should know it all by now. That I will go to say the words "I need help" and it will come out sounding like "I am not smart enough to be a developer". That I will try to say "I don't know" and everyone will hear "I am incompetent".

So I am choosing to stand fearlessly in the face of my ignorance, and to ask for help. How do you, especially the mid-level and up engineers, keep asking for help? How do you handle the pang of panic when you know you used to know this and now you don't? How do you silence the voice that says you are not good enough? How do you move forward when you can't?

Using SSH & SCP to Add Custom Remarkable Templates

Ray — Fri, 04 Jun 2021 20:59:52 +0000

Photo by Claudio Schwarz | @purzlbaum on Unsplash

Remarkable is an e-ink reading and writing tablet. It runs Codex, a custom Linux OS, and has a growing community of hackers and template creators.

I use mine for reading PDFs, doing sudoku puzzles, taking notes, planning my week, and tracking my daily tasks. For the later two I built two custom templates based on how I best organize my tasks.

Here's how I upload my custom templates and make them available on my tablet:

Download or create an .svg and .png copy of each template that you want to add. Other than the file extensions, you want both of these files to have the same name. I made mine with Sketch, but you can also download ones from the community, buy some from folks on Etsy, or email yourself a pdf from your tablet that you've drawn. Make sure that if you're creating your own that they do not have transparent backgrounds, which cause erase issues.

Look up your shh password & IP address. You'll find these on your tablet under Settings > Help > Copyrights and licenses > on the first page at the bottom.

We're going to use ssh, the SecureSHell program to connect to the tablet over usb. If you look at the tablet's Copyrights and licenses section, the sentence with the password gives an explanation of what we're doing: "This device acts as an USB ethernet device, and you can connect using the SSH protocol using the username 'root' and the password 'your password'". Put another way, the operating system on your computer will see the USB connection between your tablet and itself as a network connection just like it would between itself and any other network connection, such as your wifi router.

Lets test this connection. Attach your device to your computer via usb. Open terminal and type ssh root@10.11.99.1 and then when prompted your password. You should be rewarded with some pretty colors:

Take a few minutes to explore the file structure. We will be copying the template images to ../../usr/share/remarkable/templates/. Look around this folder and you'll see that there's a .png and a .svg for each of the templates. There's also some with an LS or P file name prefix, which denotes Landscape or Portrait, for templates with different layouts for each orientation. Exit your ssh session with control + D.

Let's get to copying! Navigate in Terminal to the folder that your template images are saved in. From here we are going to copy both of the template files to the tablet with scp, the Secure CoPy program. To do so we need to know the source of the files and the destination for the files. Since we navigated to the folder with the template images, the source directory is ./. In order to copy both .svg and .png in one go, we'll use .* as our file type. Together with the file name, this makes the source ./TemplateFileName.*. The destination is on our tablet, so we first need to use the username and IP address we used to shh, root@10.11.99.1. This address is followed up with the file path at that location where scp should put the copied files, ../../usr/share/remarkable/templates/. This makes the destination root@10.11.99.1:../../usr/share/remarkable/templates. The whole scp command is:



scp ./TemplateFileName.* root@10.11.99.1:../../usr/share/remarkable/templates

Confirm that your files copied by connecting back to your tablet with ssh root@10.11.99.1. The .svg and .png files should be in the usr/share/remarkable/templates/ directory. 🎉 The party isn't quite done yet, it's time to edit the file the tablet uses to know which templates are there.

In the templates folder you'll see the file templates.json. We're going to edit it with vi. Type vi templates.json and you'll open the vi text editor. The first object in the list of templates looks like this:



{
    "name": "Blank",
    "filename": "Blank",
    "iconCode": "\ue9fd",
    "landscape": true,
    "categories": [
        "Creative",
        "Lines",
        "Grids", 
        "Life/organize"
    ]
},

Let's break it down. "name" is the display name, this can have spaces in it and it doesn't need to match the filename. "filename" is the name of the template, without the .png or .svg extensions. "iconCode" refers to which thumbnail will be displayed with that template. You can pick which one you want for your template with this guide. "landscape" is true unless this is a portrait-only template, then it's false. "categories" lists which categories you'd like to have the template show up under.

For our template to show up we need to add a JSON object that will represent it. Bust out your Vim moves, copy the Blank object, paste a copy back in, and then edit it to that it matches your template's name, filename, and other properties. Save & exit Vim.

Now we need to tell our tablet to restart so it will re-read the templates.json file and "see" our new template. The Codex systemd is called xochitl. We'll tell it to restart with the command systemctl restart xochitl. While the tablet restarts exit your ssh with cmd+D. Once your tablet is up and running you can find your custom template among all the others.

Hack Your Brain to be a Better Developer - with Science!

Ray — Sun, 02 Feb 2020 03:53:06 +0000

At the 2020 AdieCon I spoke about 5 different issues that I’ve encountered in my 3.5 years of being a developer, my understanding of the science behind why those things happen, and what my best strategy is for dealing with that issue. I've broken them out into the following articles:

Asking For Help

Tracking Daily Activity

The More You Need to Know, The Harder it is to Remember

Use a Checklist to Un-Stuck Yourself

Success Is A Feeling

I had a blast at AdieCon and can't wait for next year!

Success Is A Feeling

Ray — Sun, 02 Feb 2020 03:52:11 +0000

This is part 5 of Hack Your Brain to be a Better Developer, my talk from AdieCon 2020.

This section doesn't have the same research behind it as the first four parts, but it's important to me, and comes from my personal experience.

In my life before Software Development I worked in Social Services, specifically in a homeless shelter, and later in low-income housing. To say that the clients and residents were folks who had and were experiencing severe trauma somehow feels like a massive understatement.

So I thought that when I came to work in software that my feelings of burnout would be easier to manage. The problem is that both careers have a commonality. Me.

When I honestly look inside, what I want in life is to be successful, to be the person who always gives 110%.

I wanted to be the best case manager. To give 110% meant being emotionally present for everyone. But I had 45 - 60 residents. Folks with histories of mental illness, disability and trauma. In a world that doesn’t believe housing is a human right. More than that, I’m human. And I couldn’t be everything for everyone.

I want all of my code to be flawless and sail through code review. I want to understand new concepts on first pass. I want to design beautiful, elegant new features. But the definition of flawless code is up for debate, it takes me time to really understand things, and not everyone agrees that my designs are elegant. More than that, I’m human. And I can’t be everything to everyone, even myself.

When we define success at giving 110% we are bound to be disappointed and to burn ourselves out trying. So here’s my best advice for my fellow folks who look inside themselves and see that what they want it to be successful. Success isn’t an outcome to be attained.

Success is a feeling. And it’s a feeling you get to define for yourself.

I've defined success for me this way:

Success is the feeling of getting up and going to do work that matters, that does good, even in little ways, with people you care about and who care about you. Success is the feeling of sitting around a big table eating food, talking, and just being together. Or going out into the world and really experiencing, moving your body through the world. Success is the feeling of coming home at the end of the day tired, but fulfilled. For me that’s what success feels like.

Go define success for yourself. You can.

Use a Checklist to Un-Stuck Yourself

Ray — Sun, 02 Feb 2020 03:51:41 +0000

This is part 4 of Hack Your Brain to be a Better Developer, my talk from AdieCon 2020.

There’s a brain resources problem that is exposed when we get so stuck that we can’t think of what to do next. We don’t have the emotional and creative resources to save the code problem, so we also don’t have the emotional and creative resources to solve the get-unstuck problem.

In times like this I turn to my three-part un-stuck yourself checklist (shout out to Coach Jennifer Underwood for the term un-stuck yourself).

Take Care of You

Do you need to eat a sandwich?
When was the last time you went outside?
Would a short nap help?

Name the Problem

Re-read the original task - are you shaving the yak?
Enumerate what you do know - you've been thinking about what you don't know, refocus on what you do know
Write one sentence that names where you are stuck

Re-frame the Problem

Have an attitude of let’s see. Reframe your one sentence as curiosity - from I don't know, to I get to find out.
What one thing can you do next? Pick the smallest unit of action you can do next. It doesn't have to solve the problem! In fact it probably won't, and that's ok, the goal is get going.
Do it!

Now you've gone from so stuck you can't think, to taking action towards your goal. Congrats!

The More You Need to Know, The Harder it is to Remember

Ray — Sun, 02 Feb 2020 03:51:26 +0000

This is part 3 of Hack Your Brain to be a Better Developer, my talk from AdieCon 2020.

There’s an error code that I get sometimes in Android Studio. I can remember now what it is, but for years - yes years - I’d see it, realize that I’d seen it before, and not be able to remember how to fix it.

The issue with human long-term memory isn’t storage, it’s recall. The more often you remember something, the easier it is to remember it. The less often you deal with something, the harder it is to recall.

Keep your own personal Stack Overflow.

There are a plethora of note taking apps (make sure you’re not violating your work’s data privacy though!), but text files in a central location you can grep are just as good.

Some of the things that I keep:

Error Codes - group by IDE & language if you can
Common APIs & requests - especially ones you use to answer customer tickets!
“Basic” questions - I always have to look up ternary operator syntax!
Good code examples - From code reviews or open source projects, tagged with why you liked them (ex: Clean Factory Setup, or Mocking Date/Time)
Set up instructions for specific devices - Android vs iPhone, your different smart speakers, etc

Workspace setup - your dot files, the settings of software you use on a regular basis if you can export them. These should definitely be backed up to an external HD or cloud. In the first 2.5 years at work I used the same computer. In the last year I’ve gone through two more. Trust me on the importance of backing up!

Where you can update open source documentation, team or company specific wiki’s, do it, but a just-for-you source is also worthwhile.

Tracking Daily Activity

Ray — Sun, 02 Feb 2020 03:51:06 +0000

This is part 2 of Hack Your Brain to be a Better Developer, my talk from AdieCon 2020.

You’re writing tests. You’ve got a mental map of how pieces of code work with each other, and an idea of what structures you’re going to set up for the test. You make mental note to change this var to that var. Then you realize you need to look something up, there’s a meeting, or the service you run tests through is suddenly down. You address the issue/attend the meeting, and switch back. Wait, what were you doing again?

The work we as developers is working memory intensive - make and track connections, update ideas, and task-switch. Memory research shows these tasks use the same WMC - working memory capacity, and we all know what happens when more memory is required than what is available:

Brain Stack Overflow

So aside from avoiding interruption, what can we do? I’ve tried a bunch of things and the best solution I’ve come across is to keep a timestamped diary. Note the time, what I’m working on, where in the code I’m working, and why I’m doing it. When my working memory capacity is hijaked by something else I’ve got a log to reference.

I also find this helpful for validating how much time tasks are taking, so I can keep at something that’s difficult but I haven’t actually been at that long, or pivot to a new tactic when the log shows I’ve been at it for a while.

Asking For Help

Ray — Sun, 02 Feb 2020 03:50:12 +0000

This is part 1 of Hack Your Brain to be a Better Developer, my talk from AdieCon 2020.

You’re so stuck on this ticket, and need to ask for help, but you’re been working on this ticket for far to long, should have asked that senior dev for help days ago.
Imagine starting to stand up to go talk to that person. How does that feel in your body? Stomach? Shoulders? For me this is a tightness in the middle of my chest.
Suddenly you realize that there’s one more thing you could try, one more thing to search the internet for, and you sit back down.
How does that feel in your body? Stomach? Shoulders?
Good, better, right?

Bad News friends. Avoiding asking for help is increasing your fear of asking for help.

Studies have shown that people with lower back injury who cope with pain, that is they tolerate some pain while recovering or doing physical therapy, recover quicker and have less long-term pain than people who avoid pain.
In medicine this is called Fear-Avoidance, in psychology it’s called Avoidance Coping.

So the question is, how do we avoid avoiding?

Knowledge is Power - knowing that avoiding will make it worse is often enough to help us do what we need to do. "This is no fun, but I don’t want to see what happens if it gets worse."
Get comfortable being uncomfortable - take the time to just sit with and really feel your discomfort. When you’ve sat with a feeling before it’s still uncomfortable, but now you know it won’t kill you.
Lower the Barrier - acknowledge that you will avoid at some point, saying you’ll never do this again isn’t realistic. What can you do to make it easier to ask after you’ve avoided?

My trick for lowering the barrier is to write out my question, and then leave in the text box of the DM or chat room where I should be asking the question. I hit send yet though - this is where I let my self avoid. I set a timer for a short but reasonable amount of time, 5 to 15 minutes. When the timer goes off, I flip over to the DM or chat room and press send. I don't re-read what I wrote, just hit send. It’s scary, but it’s worth it, and now the question has been asked!

Dev 101: Unicode

Ray — Wed, 06 Mar 2019 06:06:07 +0000

What is it?

Unicode is a standard of encoding sets and characters established by The Unicode Consortium. It is the most widely used standard, makes internationalization easier, and the reason we can have emoji 😍

Why do we need it?

If you gather, display, transmit or otherwise use strings on the internet, desktop software, or mobile apps, then you need to encode them. Unicode maintains the most popular standard, UTF-8 [1]. Understanding it is key to being a competent developer[2]). (It was also named one of the 12 Things Every Junior Developer Should Learn[3]) Failing to understand and properly use it can result in those empty boxes, odd-looking question marks, and general frustration for you and whoever wants to use whatever it is you've coded up.

Where did it come from?

Let's back up and talk about where letters come from. Spoken language is a way we humans have figured out how to encode meaning in sound. If I say "Hello" you understand that I'm greeting you. Written language encodes those sounds, so when I write "World", you understand I'm talking about our planet and all of humanity. That is if you understand the spoken and written language I'm using.

If you don't understand the language I'm using then my sounds or arrangement of symbols mean nothing. Computers don't understand human languages, they operate using binary. So if we want to use a computer to gather, display, transmit or otherwise understand a human language we have to give the instructions to it in binary.

Encodings between binaries and characters make this possible. Different types of computers used to have different encodings and this worked just fine until we wanted to share information between computers. To do that we need to have an encoding standard that both computers share so that when a set of binaries is received the correct letters are displayed or save. In 1963 the American Standard Code for Information Interchange (ASCII) became that standard.

ASCII has uppercase, lowercase, punctuation, symbols, and control codes. It lacked accented characters like è, non-American symbols like £ or any non-latin characters, but it got the job done. The ASCII set was 128 8-bit characters which left 128 characters free. This lead to a hybrid of pre-standard and standard encoding evolved. The first 128 characters were the ASCII standard, the last 128 bits used by different groups to encode different symbols and letters.

Clashes between the way different machines used those last 128 characters happened, but it was good enough, and ASCII was the standard for three decades. Support for many more languages and their characters lead to the publication of Unicode in 1991. Unicode has evolved a bit over the years, from all 16-bit characters to the current standard, UTF-8, which is variable length encoding.

In UTF-8 the first 128 bytes are just like ASCII. This means that the most commonly used characters on the internet still just use one byte per character. After that characters aren't limited to one byte, instead they can be two, three or four! Having the set of characters supported by ASCII take up the least amount of space in UTF-8 makes sense given that most of the internet uses UTF-8 (93% of websites), but it still gives us access to all the other characters that Unicode supports.

So what doesn't Unicode do well? Most of the Unicode issues relate to Unicode providing single characters which are then displayed in different ways depending on their fonts. Characters that are different but look similar make homograph attacks possible. Chinese, Japanese, & Korean all share a character set in Unicode, relying on different fonts to differentiate between the way each language displays those characters. In languages like Arabic and Vietnamese single characters are connected with ligatures to make glyphs, meaning that any given character might look different depending on what characters it's connected to (think cursive writing in English). For these languages Unicode and fonts aren't enough and secondary processing needs to be done to display them correctly.

And last, but not least, the new international language, emoji, are even subject to this font issue. Emoji are a bit more consistent than they used to be, but differences still exist between platforms. The most notable difference is the the dizzy face, which reads more like death on some platforms.

Summary

You should care about character encoding becuase it is how we store and display language on computers.
Unicode, and specifically UTF-8 is the most widly used character encoding on the internet.
It uses variable length encoding to give us fast loading for what we use most, while also providing us with more than 137,000 other characters.
Unicode, like ASCII before it, is character encoding only, relying on fonts for language diferentiation and emoji style.
Emoji are 🎉 🙌🏼 💻 🔥 😍

Discuss
What's your fav emoji? What are your top used emoji? What do they mean to you/what are you trying to say with them when you use them?

Design Reviews for Existing Features

Ray — Tue, 22 Jan 2019 04:58:16 +0000

Recently I've taken on the project of helping organize my team's design review process. Part of what we want to do is have "design reviews" for our existing features, the outcome of which would be a desgin review meeting about that feature as well as new documentation about that feature.

Currently we're asking folks writing design reviews for exisiting features to answer the following questions:

What is this feature?
- What was it initially designed to do?
- What do customers expect it to do?
How does it work?
- What are the components of this feature?
- What technologies do they use?
- How do they work together to create the feature?

How does your team maintain knowledge about your existing features? How do you go about figuring them out in the absence of updated (or any) documentation? Are there any other questions you would ask in a design review for an existing features?