Forem: Riaz Virani

Five Tips for Success: How To Thrive At Your First Dev Job

Riaz Virani — Wed, 11 Aug 2021 01:20:21 +0000

So you're trying to break into the industry and spending all your nights and weekends on code exercises, building your portfolio, and just generally being a sponge for all knowledge. Then...you get the job.

First, congratulations for your hypothetical self. But it turns out you've only won half the battle. As a senior engineer who's hired multiple juniors, the first year as a full time developer can be tough. I've seen it work with both fantastical success and seen people struggle.

What makes the difference?

It's not pure technical know how. It's knowing how to ask for help. It's knowing how to help your manager, who is not an expert in nurturing junior developers, help you develop. Luckily, there are strategies you can follow. Here are FIVE that will definitely help.

Tip 1: Ask and You Shall Receive

If you're new at something, you naturally fear the things you don't know to know. So you'll worry about looking like an imposter if you ask the "wrong" question or just too many questions. I've seen developers get stuck and thrash for days in silent frustration rather than ask for help. Worst of all, I've seen some developers glorify this sinkhole of futility as a rite of passage.

Junior developers err on the side of asking for too little help rather than too much

Banging your head on the wall for more than a few hours is not helping you learn nor helping your company. Ask, but ask intelligently and involve others progressively. Don't throw your hands up in the air. Push your team to give you just enough help to you get unstuck and keep going. This feels kind of abstract, so let's try a real example.

Let's imagine you are stuck on a coding problem. You're even unsure as to whether your approach makes sense. Either way, you just feel lost. So here's what your next morning standup update could be:

Hi everyone, so I'm currently working on X feature. I'm not sure how to approach it. But right now, I'm trying Y. I'm going to keep at it this morning, but if I don't make good progress. Would it make sense to grab someone else from the team really quickly to talk through it and get me unstuck?"

If I managed this team, this would blow me away. You've essentially done my job for me. I don't have to pry open your current status to figure out whether there is a risk to manage. You haven't thrown up your hands and just tossed it to someone else. You haven't given me a bullshit answer. You've identified a challenge, established at timeline to work on it, and then recommended the next step that involves the least amount of resources to keep you progressing. This is called "managing up" and it's a tremendous skill whenever you are in a new field.

Tip 2: Write Now, Worry Later

So you do figure out a solution to the problem mentioned above. You feel relieved. That was hard! You proudly submit a PR for review. The next day you wake to find that a senior developer has requested a dozen changes and asks that you rethink your whole approach. You feel like you've just been punched in the gut. Your self-confidence is shot to hell. Can you even do this job?

The real tragedy here is that the senior engineer may have no idea they caused any emotional turmoil. They're just in their own little world tackling a task list, but with a little bit of empathy they could make a huge difference. What if one of those notes looked like this:

Hey, I know this is a lot, but that's expected. You're learning and you've made a ton of progress. If you have any questions, I'm happy to help.

Empathy matters. Without a note like this, the junior developer becomes terrified of their next PR. This is a bad place to be.

So what's the solution?

There are a couple of solutions here. One is to "manage up" liked we talked about in the last tip. Ask for weekly or biweekly check ins with whomever is your lead so that you can just ask "Hey, how am I doing?", "Where can I improve?". If they have criticism, listen to it. It's better than guessing or worrying.

The second is to just understand that code is inherently flawed. All the talks in the world you've listened to about how we can do "coding right". Yet all those same presenters have the same problems in their code bases as you. It's just how this business works. Don't get me wrong. Shitty code is very different from flawed code written by people trying their best. There are a lot of shades of grey here.

You just have to internalize that you only figure out the right path by trying a lot of the wrong ones. That means you can't be afraid of your code. Some of it will suck. If it's a process to learn, then get through it as quickly as possible. Give it your best shot. Feel the pain of debugging it and then iterate till it's less painful.

Tip 3: Go Deep, Not Wide

When you're starting, learning too many things can actually hurt you. You can try all the JS frameworks, fiddle with Docker and Kubernetes, and play with CSS. All the things! This is also how most bootcamps work. They'll spend just a few weeks on a multitude of technologies in order to market how many things you'll learn. In the end though, you might not know enough of any one thing to contribute on a team.

You only need one foot in the door, so get good at one thing to start

Figure out the one thing you're tried that you really enjoy. It could be CSS and design. It could be DevOps. It could be iOS development. Whatever! Then ask your team lead to give you work in that area and just focus on learning how to do that thing at an advanced level.

You'll very quickly gain credibility with your team because you've now got a domain where they can ask you for help. You'll feel more confident and now have a strong foothold to buy time to learn all the adjacent technologies.

Damn, you must like to read if you're all the way down here. Don't worry the last two tips are super short

Tip 4: Don't Put Your Teammates on a Pedestal

Earlier we talked about getting help. So let's say you pair with a senior developer and they give you a recommended approach. You try it out, but it doesn't seem to work. Are you just implementing it wrong or is the approach faulty? You don't want to disappoint or contradict the senior developer, so you shoehorn it in. You write a bunch of hacky, clumsy code to make it work. Upon review, the developer who gave you the approach sees its flaws and changes his mind. You have a palm in face moment.

Senior developers make just as many mistakes as junior ones

The big tip here is that if something is painful to you, that means its actually painful and that's valuable information. You get to have an opinion because you also live in this code base. The most valuable thing you can do is articulate that pain. You'll be amazed at how often your pain points will match others even if they've been silent about it.

Tip 5: Pseudocode is your Friend

Most senior developers generally don't write pseudocode before writing the actual code. They've been doing this so long, they can maybe even think in code. If that's not you yet, then here's a little practical tip that can sometimes do wonders.

Don't think through the logic and syntax at the same time

Try just putting comments where the code will go describing it. Let it read like human phrases or sentences. Once you have that down, just translate each comment into the syntax of the programming language. You're making it easier for your brain to do one thing at a time, which means it can be more efficient.

Yeah, this tip is a bit of an outlier since it's not some grand concept. But it does work. Try it!

That's all folks. Super practical, simple tips to help you succeed.

Should Your Next Backend Be Serverless?: A Perspective From Someone in the Trenches

Riaz Virani — Sun, 25 Jul 2021 17:22:52 +0000

Serverless technologies are definitely the new "hotness", but does the hype live up to the reality?

I recently completed a project called Listeri where I went all in on serverless after a decade of writing traditional backends. Here's what I learned:

What does "serverless" mean?

TLDR: Skip this if you are familiar with serverless as a concept

For those of you that aren't familiar with the term, "serverless" doesn't mean there aren't servers. It just means you don't run the servers.

Let's think about a typical backend. You have a server, which is just a computer somewhere. It runs your application in the background and waits for web requests. You pay for the whole server with all of its memory and CPU no matter how many requests come in and out. I understand there are some variations here in more complicated contexts with autoscaling, docker hackery, and virtualization. Let's just keep it simple for our example. So you've got your computer running somewhere. Now if tomorrow you hit get featured on Hacker New and your user base gets 100x bigger, you have to figure out how to add more servers to handle that load. If that doesn't happen, you are still stuck paying for a full server when you only need part of it.

Serverless technologies, like AWS Lambda, Netlify Functions, Vercel functions, etc turn that on its head. You don't boot up a server. You just give them your code. It stays dormant until someone makes a web request. The serverless provider then boots up your code, runs it, returns the response. You only pay for the little bit of compute you used. Sounds amazing, right!

What's the catch?

Like every new technology, there's a ton of marketing by the providers and tech zeitgeist telling you how to implement serverless functions, but not a lot about whether you should.

The Dreaded Cold Boot

Problem: Serverless providers can offer such cheap service because they generally don't keep your code running. If no one visits your site or hits that endpoint for a bit of time, then they put your code to sleep. The next person that visits will often see a 5-7 second delay in getting a response while your code gets booted back up. This can vary a lot by provider.

Workaround:

Have a ton of traffic - This isn't a problem if you have a high frequency API that's getting hit all day. If you have a smaller site or API, then it can really ruin the user experience. It will also feel erratic to the user since it will only happen once and then the site will feel fast.
Keep Hitting Your Own API to Keep it Alive - Yeah, this is a hack, but even the noble developers over at the serverless framework kind of recommend this.
Use AWS Lambda and fiddle with Provisioned Concurrency - Realizing this is a big problem. Amazon is trying to make it less impactful. There is a setting in AWS Lambda to try and reduce the cold boot time, but it doesn't eliminate it entirely. Cloudflare Workers also have an approach to minimize cold boots, but it results in other compromises I won't go into here.

Basically, cold boots can be a problem and the right solution isn't clear yet. Everyone is still experimenting with ways to solve it.

Database, Anyone?

Problem: Most major databases aren't yet built to work with serverless technologies, including MongoDB, PostgresQL, or MySQL. Remember that when your function goes idle, it shuts down. That means it loses its active database connection. That connection has to be reestablished when you boot back up. In a normal server, the connection is persistent since your server is always up. This can create a significant performance issue for your app that's hard to discover.

Secondly, most hosts for these traditional databases have connection limits as to how many connections you can have open. Serverless providers scale up the number of copies they have of your code running on different machines as they see fit. This means you can very easily blow your connection limit without realizing it. For example, MongoDB Atlas (a Mongo hosting provider) has a 500 connection limit even on their serverless tier! Connections are also very memory intensive for traditional databases so it can hurt performance.

Workaround

Use a Database With High Connection Limits - You can just brute force this by running your own database server on a big machine but now you have to manage a database server! You can also try DigitalOcean's Managed Postgres service, which has PG Bouncer built in. That means you can get up to 5000 connections per database on Digital Ocean.
Use Amazon DynamoDB or FaunaDB - Neither of these have connection limits issues. Dynamo can be really hard to query though and FaunaDB is not as battle tested as MongoDB.
Use Amazon Aurora Serverless With a Data API - This is Amazon's clever way of allowing you to use Postgres and MySQL without a traditional database connection. Instead you make HTTP API calls to your database. This isn't great for performance since now you have the overhead of a SSL handshake to make a database call. This solution is also very very new at the time of writing this article.
Don't Work Around It - Just hope you never get big enough to have this problem. That's kind of ironic though since you probably want to go get big enough to have this problem.

Performance, What?

Problem: In a traditional environment, there is pretty mature tooling for most languages / frameworks to measure performance. That's just not true in serverless, yet. You can measure the total response time for a call, but there are a lot of other factors outside of your code that could impact timings. Was it a cold boot? Was it a cold boot with a delay in connecting to a database? Did your serverless provider glitch and leave you on a box where someone else took all the CPU? Unlike a normal server, you can't look at a chart and see that somehow the CPU spiked. Remember, you can't look at the server!

Workaround:

Add a bunch of logging and tooling by hand - Yeah and guess?

Conclusion

Serverless technologies work, but the ecosystem isn't there in terms of databases, performance management, and reliability to replace traditional server architecture. Even the big players are still experimenting with solutions they might throw away in a few years. If that's fine with you, then go for it. Just do it with eyes open and not clouded by the chatter in the techverse.

Five Dev Podcasts You Should Be Listening To

Riaz Virani — Mon, 19 Jul 2021 01:31:48 +0000

I got asked a while back what I listen to as an avid podcast listener. So I thought I'd make a quick post of some of my fav tech related podcasts.

The ReadME Podcast
The ChangeLog
CoRecursive
Software Engineering Daily
Masters of Scale

Hack your own powerful Chromebook for less than $200

Riaz Virani — Wed, 07 Jul 2021 13:48:30 +0000

Alright, so you have your main computer, a great powerful MacBook or Windows notebook, that can command the power of the gods on demand. 80 gigabytes in your node_modules directory? No problem for this beast.

But sometimes wouldn't it be great just to have just one more computer? Let's say your friend comes over and forgets his computer. So not only are they eating those amazing cookies you got for yourself but also using your damn computer and snooping across your email. Yeah, we've all been there.

I'm often surprised at how often programmers assume they need to spend like a thousand dollars on every computer since that's what they use themselves. In fact, there is a super cheap way you can build a powerful (not slow) Chromebook yourself for around $200 or less.

Here's how you do it!

Get a computer

Go on eBay and find a used business class laptop that's 3-4 years old.

See a lot of big companies acquire Dell, HP, and Lenovo business notebooks in masse. Their employees use the machines for 3 years and then they sell them to wholesalers who retail them as used laptops. These wholesalers clean them up, install a new Windows license, and then sell them at a premium. However, some will sell them as-is without any reconditioning for super cheap. That's what we are looking for. We're also specifically looking at business class laptops since they are way more durable than the consumer class laptops that you might normally see at a retail store.

Here's a good example of one a Dell 5480

The HP EliteBooks are also a good choice. You can see a list of them on Wikipedia. The older the unit, the slower and cheaper.

Install CloudReady by Neverware

Make sure the laptop is certified by Neverware as compatible. This is the Google owned company that makes a version of Chrome OS that can be installed anywhere. Most business class laptops are certified though.

Adjust coffee table to perfect height using laptop as paper weight.

Just kidding, go enjoy your new Chromebook

Ten Ruby gems for Rails you should definitely know about

Riaz Virani — Sat, 26 Jun 2021 02:00:34 +0000

Whenever I join a new project, I love scooping through their Gemfile and digging about. It's kind of like looking through someone else's apartment only to discover that essential oil diffusers are a thing Those things are amazing!. Weirdly voyeuristic, but incredibly useful to discover new things.

Over the years, I've found that many of us don't know about popular gems that could be of help to us. So here is my list of ten gems you should know about if you don't already. Well, if you already know of them, you've just wasted a few minutes of your life...

Kaminari

Kaminari hooks onto ActiveRecord associations and makes it super easy to page them. Pagy is another option that seems to have a solid API but I haven't tried it yet.

Counter Culture

If you've ever used Rails counter caches (basically help you keep track of the number of related records in a database) but found sometimes you need something a little different. For example, you needed to track the sum of the values in a different table instead of a count of records, then counter culture is for you. I've used it on many projects and it's been rock solid.

LightService

LightService is my favorite gem for organizing business logic. If you've ever heard about railway programming, that's basically what this gem helps you do. Again, used it for years with no issues.

Geocoder

This is hands down the best gem to use if you're trying to convert locations to latitude / longitude coordinates or vice versa. It supports a wide variety of APIs, like Google, etc.

Lockbox

This gem is just too good. It makes it crazy seamless to encrypt the contents of a database field. However, ActiveRecord basically gets to behave as if it's not encrypted.

Money-Rails

Money or as I like to call it...monies. Money rails gives you great tools to manage money and multiple currencies straight up in your Rails application.

ViewComponent

ViewComponent is GitHub's take on expanding upon the partials system in Rails. ViewComponents are a great adaptation to bring the component model that's so common in front end architecture to Rails.

StrongMigrations

Strong migrations runs some linters on your database migrations to make sure you structure your database correctly. It has made I don't shoot myself in the foot many times.

Phony Rails

Just like the money-rails gem above, this gem is all about phone numbers. It makes it really easy to track area codes and standardizes your database to always save phone numbers in the IETF format. Trust me, just use it.

That's it

Wait, you say that's only 9 gems. What can you do? Off by one errors...

So I tried Svelte and it was...interesting

Riaz Virani — Sat, 20 Mar 2021 03:33:34 +0000

When I first started writing my blog, I wanted to try something new. I‘m a big believer in doing what you know works for production, but still taking advantage of opportunities to try new things.

What is Svelte?

Svelte is a framework a la React and Vue. It uses a componentized approach just like those frameworks. However, it compiles down to plain JS with no runtime. That way it‘s smaller. It also looks a lot more like plain HTML and JS rather than weird custom syntax (I‘m looking at your Angular). It also has first class support for animations, which some other frameworks (cough React) don‘t have.

However, there are some problems...

The build ecosystem and routing solutions are a bit of a mess and the maintainers keep changing their mind (despite being well intentioned).

For example, Svelte initially came with a CLI, then the maintainers switched to a format where they give you a template repo and you clone it via a custom tool called degit. They now want to move back to a CLI in a future release.

The recommended Svelte build tool is called Sapper. It‘s been deprecated in favor of a to be released build tool called Svelte Kit that is months and months delayed as of March 2021. They‘re also moving it to Snowpack for reasons? However even sticking with Sapper, I had a lot of obvious issues, like styling the body tag without triggering a Sapper warning. Build times for any non-trivial app can also get quite long using the webpack version of Sapper, which is something the maintainers acknowledge but can‘t fix until SvelteKit.

Additionally, one of the principles of the framework is to bind JS to the UI in a way that looks like normal JS. However, this can lead to some problems. You think you‘re looking at var a = "b" But it‘s actually doing a ton of magic to watch the value that expression to update the DOM. So when it goes wrong. It‘s a little hard to debug.

Conclusion

First of all, this is just my opinion and this was my first attempt at using Svelte. However, chances are you‘re in the same boat, so I thought my insights could be valuable. I‘ve said a lot of negative things here, but I don‘t mean to rant. I really like Svelte‘s first class support for animations and the fact that it doesn‘t need to start up a runtime on the client to work. That means Svelte sites are generally fast after compilation. However, the ecosystem needs some more attention. It doesn‘t just need to be bigger but needs for the maintainers to stop using it for experimentation. If an idea is good at one point, it needs overwhelming reasons to change.