Blog

  • Exception-Driven Development Gives You Back Your Time and Sanity

    Hello, friends!

    I’ve been doing software development professionally for a few years now, and I’m noticing a trend in newer languages that I’m really liking: putting errors front and center.

    This is a very welcome development that benefits developers everywhere. Take it from someone who has developed web apps professionally using vanilla JavaScript! The languages seems almost eager to trick you into doing silly things like using double-equals instead of triple-equals.

    This is because JavaScript’s design philosophy wants to avoid crashing under almost any circumstances, even if data ends up being corrupted due to silent, sneaky errors later on. This can be a real pain for devs, as debugging is a huge part of the job. The deadly combo of a wonky type system and a language that doesn’t emphasize handling or acknowledging errors when they come up can lead to some serious headaches and wasted time!

    You can compensate for these faults of JavaScript by being super vigilant about types, unit testing, and other such practices. The problem is that this leads to a lot of extra mental load, because the language passed the buck to the developer. Slow feedback loops on new code, since the reviewer needs to be as or more defensive than the original author, and missed corner cases are also a big risk with dynamically typed languages.

    Enter Go and Rust. These newer languages have smaller ecosystems than more established players like Java, C# and JavaScript/TypeScript, but their design places high importance on handling errors as they come up. In Go land, the if err != nil pattern is the cause of much hand-wringing, but I can tell you that trying to manually reason about and remember error conditions in your code leads to much more pain in short order. Even worse if you have to look at the docs just to know that something can return an error at all!

    One can argue that CI/CD can also catch many such errors and code smells, but that stuff costs much more time and money to run than the Go or Rust compiler.

    interestingly, the newer typed languages (I hesitate to call Go strongly-typed compared to TypeScript or even Java) can sometimes even beat dynamically-typed languages at their own game. Errors can be handled simply by logging them, so you can iterate quickly while still having types and strictness around errors!

    if you enjoy reading my posts, please subscribe to this blog by entering your email. 🙂

    Make a one-time donation

    Like my work? Consider donating!

    $1.00
    $2.00
    $5.00

    Custom donation amount:

    $

    Your contribution is appreciated.

    Donate
  • Ventoy Is Saving Me Time, Money, and USB Sticks!

    Hello, friends!

    I’ve been using a brilliant tool called Ventoy, recently, and I wanted to tell you guys about it.

    When I started out in my Linux journey in 2014, I learned to flash a single ISO disc image file to a USB stick, which would require formatting the USB key each time, and allowed for only one OS at a time to be bootable from the stick. Naturally, this would get in the way when I was in a seriously experimental mood, so I would keep around many flash drives.

    This all changed recently.

    Ventoy makes it so that you can have multiple bootable ISOs on a USB stick, as well as shared memory space persistent across restarts! You can also store any other kind of file you’d like, so all your OS’s and your data can live happily together 🙂

    This has completely changed the game for me. I now need to have less USB sticks lying around, so I don’t need to remember which of my USB sticks had my backed up data, and which had which operating system loaded on it. Now they all have important data, as well as a smattering of operating systems I like, such as Linux, some BSD OS’s, and reluctantly, a Windows 10 ISO, which has come in handy for helping out family members.

    I also no longer need to keep formatting and overwriting my USB sticks, so hopefully that will allow them to last longer, as well. I can safely say that Ventoy has completely changed my life as a Linux user! 😀

  • The Abysmal State of Contract Software Development

    The whole point of working a contract gig, instead of the traditional salaried job, was that you made a choice to trade stability for flexibility and short-term financial gain. The flexibility meant that, on paper, you could work multiple contracts, if you wanted. Unfortunately, this isn’t really true anymore, as companies hire large groups of contractors who aren’t paid benefits and can be let go with a lot less hassle, while also giving them less money than full-time employees.

    I’d know. I was one of them, several times.

    Aside from the stuff I already mentioned, there’s some other key problems with staffing companies that are making it so contractors really get the short end of the stick in every way possible.

    Before I get further into the problems with modern contract software development, I’d like to mention that one big upside of contracting is the contract-to-hire arrangement. It’s when you work a short contract period, and then the client company (in my case, Chase Bank) decides if they want to bring you on as a full-time employee, which they did for me. I am vocal about people staying far away from working for Chase, but that’s a separate issue, and i often encouraged people in the past to go contract-to-hire to get their foot in the door as a software engineer.

    Worse Pay and Benefits Than Full-Time Employees

    I’m going to emphasize this point again, since it really rubs me the wrong way that people who are sacrificing the stability of a salary are also getting paid less. A contractor can still get some kinds of employee benefits through their staffing company, but these tend to be a lot worse than what the client themselves would provide, and on top of that, you’re still making less than FTEs, even if you waive those employee benefits.

    Oh, and you don’t get paid time off at all. If you’re sick or otherwise need a day off, you just don’t get paid. This would be understandable if all the other issues I talked about didn’t exist, but as it is, it’s kind of just more salt in the wound.

    Miscommunication About Roles Is The Norm

    A big way in which contractors are set up to fail is there is often a severe disparity between what the contractor is told they will be doing, and the actual work they end up being assigned. In one extreme case, I interviewed for, and was offered a backend role in Java and Spring Boot, with a little React and JavaScript. What actually happened was that I barely got to write or maintain any Java code, and was expected to almost exclusively write React. The other contractor and I also had to fix the broken Jest tests, extremely sluggish Webpack configuration, and snapshot tests we inherited from another team.

    After two months, we were both let go, citing completely made up and unsubstantiated “performance reasons”. I learned this was the case when I tried to log in to work on a Monday morning, and my credentials didn’t work, which prompted me to call my contact at the staffing company. I knew these “performance reasons” were just that, because the other contractor was awesome at his job. Him and I also had to spend the whole first month at the contract just getting set up and onboarded into Chase’s systems, like the databases, ID systems, computer networks, and such, with many issues along the way that were out of my, the other contractor’s, or the manager’s control.

    Another painful mismatch I encountered was when I was assigned to a multinational healthcare client to do backend Java development. After another long, red-tape filled onboarding process, I was actually made to do long-running, tedious data exports that I was told was supposed to be automated, but the seniors were also swamped with dozens of said data exports themselves, and we had to meet service level agreements that were promised by the business. I was also expected to randomly bang out SQL queries and other kinds of reports on-demand by management. Weirdly, I did on-call rotations with this team, but wasn’t paid for being on-call on a Saturday morning; my timesheet with hours put in for Saturday was flatly rejected, and my boss called me and asked me why I added those hours.

    I later found out that my staffing company didn’t want to pay me overtime for those extra hours. I was later cut from this contract, being told over the phone that “not everyone can make it at XYZ Client”. Completely ignoring the fact that I was set up to fail.

    Long story short, contractors now get all the downsides and none of the upsides of contract work. If someone can turn a contract into a full-time job, that’s great, but contractors have been a second-class citizen in every company I’ve worked as one.

  • “Just Keep Applying” Isn’t Persistence, It’s Insanity

    Hello, friends! 😀

    It’s been occurring to me more and more often, lately, that as job seekers, we are told to keep doing the exact same things on a loop.

    Keep “updating your resume”. Keep “networking”. Keep “upskilling” and getting new certifications. As if people who already have those certifications aren’t just as unemployed as the rest of us. Not to mention that I already have on the job experience with those tools, like AWS anyways.

    Last, but not least, “it must be your resume”. Trust me, there’s only so many ways to spin it when all your software engineering experience is in the same boring old enterprise-friendly tech stack (Spring Boot, Java, React).

    Many people who say this to me are well-intentioned, and were lucky enough to have great careers. Good for them! But times have been so bad for the past year, that people are wondering if the white-collar career as we knew it is dead and gone. I wish people would be a bit supportive, and give people room to explore new things, instead of rattling off the same old “advice” constantly, to the point where they are just blaming the victim.

    Speaking of blaming the victim, you’re also told constantly that you can’t badmouth employers, point out abuse, object against clearly bad ideas/processes, or anything that might demonstrate some kind of self-preservation. Yet companies lie constantly to candidates, or change up their working arrangement without any warning, as a “soft layoff” tactic. They also routinely post “ghost jobs” that they have no intention of ever filling. And let’s not forget that big companies get bailed out constantly, despite sometimes receiving small fines for misconduct and market manipulation

    Makes you wonder why there’s so many double standards. It’s because fairness isn’t the point

    I’ve also been discriminated against on the basis of my religion, while working at Chase, and have worked more than once in toxic and verbally abusive environments. One of these places also had so many hours of pointless meetings per day, and such a lack of documentation, that I struggled to get any work done. I would have to work around the endless meetings, that were sometimes unscheduled, and outside of that, I had to spend hours in calls with other engineers, because the system was poorly built, and not documented at all. It would take changes to more than 10 files in the project just to add a new endpoint to our Java 8 web application, when it shouldn’t take more changes than can fit on one hand.

    On an unrelated note, this same system lost track of 10,000+ users’ data in one fell swoop, and releases were riddled with bugs. This was a healthcare payments company, so it wasn’t a great time for them.

    Personally, I am still doing the traditional job hunt a little bit, but I’m now investing more time and effort into my blog and YouTube channel about software development and operating systems. I think the way forward for most of us is going to be starting our own monetized channels, income streams, and small businesses, because I’ve been cast aside by too many large corporations, too abruptly, to have faith in working for them anymore. It’s the only way we can change the situation we’re in, as the established players like Google, Microsoft, and such, are too big to lose. We’ll just have to do our best to take our ball and go home, wherever possible.

    If you enjoyed this post, please share it with your friends, and subscribe to this blog!

  • I Streamed Myself Writing Code For The First Time Yesterday!

    Hello, friends!

    I streamed myself writing code on my YouTube channel today! It was a pretty fun time, and I finished 4 of 22 parts (structs, enums, strings, and modules) of the Rustlings tutorial. I covereed structs, enums, strings, and modules in this session, and had a blast talking with one of my friends.

    There weren’t many viewers this time as this first stream was pretty spontaneous, but I shall also be streaming myself writing some more Rust code tomorrow at 5PM Eastern TIme! I look forward to seeing a few people show up, so I can chat with you all, and we can all learn ourselves a bit of Rust! 😀

  • Zero to Web in Rust – Rustlings is The Coolest Tutorial Ever!

    Hello, friends! I hope you’re all doing super well!

    After hearing friends and many people on the Internet talk about Rust for quite a long time, I decided I would take the plunge and start learning it! I had made some short-lived attempts to learn the language before, but I didn’t stick with it. This time is different, however, for a few reasons.

    For one, I’ve decided that i will document my journey in Rust on this blog. As you may have guessed, my goal is to build a web application in Rust; I will probably recreate Google Keep or something similar, as I find it to be a useful app. Unfortunately, it also runs the risk of being sunsetted by Google at any moment. It’s just something that Google has done with a lot of its products over the years. I’m not entirely sure why.

    Anyway, I wanted to tell you all that Rustlings is an awesome way to pick up Rust by actually writing bits of code! The approach has been a lot better than I thought it would be, since each unit test takes just a one or two small changes to pass, so you get to write just enough code to train your fingers on how Rust code feels to write. You don’t have to worry about getting bogged down in picking out libraries or frameworks for a project, you write just enough code to get familiar with a concept, with instant feedback from the delightful Rust compiler and Rustlings test suite!

    Aside from being interactive and providing a rapid feedback loop, Rustlings is made to correspond to the freely available Rust Book, also a great first-party resource from the Rust team! 😀

    This first image displays a very friendly error message from Rust. I used the wrong syntax to get the element at index 1 of a tuple, so it told me exactly how to solve the error. Languages such as Python and even C++ are also adopting these sorts of helpful error messages. I can say it’s a very welcome improvement over having to Google basic bits of syntax when learning a new language, or returning to an old one after a long time.

    This second image shows that each exercise automatically turns green in the side bar when a file is saved. It’s much friendlier than manually rerunning tests. Simply rerunning tests on save is a smart idea that I wish I had thought of, but it’s something that comes with the Rustlings exercises. Speaking of which, here’s the GitHub repository for those exercises.

    Give Rustlings a go! You won’t regret it!

    Thanks for making it to the end of this article. Be sure to subscribe, and stay turned for my next posts, since I’m still going to be doing the Rustlings exercises for a few more days. I plan to post about creating a Rusty REST API, with a blazing-fastâ„¢ UI library. I’d love to hear your thoughts about which libraries or frameworks would be best for these tasks! 🙂

  • I Don’t Want to Be Just a Software Developer Anymore

    “You’ll burn out within five years in software development.”

    I think about this quote from my dad a lot. It’s something he said to me when we were discussing corporate careers a few years ago, and it turns out that this prophecy is slowly coming true.

    Just not in a way either of us really expected.

    For my part, I expected that my dad’s premise would be false. I was wrong. Sort of. I still want to do software development, I just don’t want to do it in a corporate office, day in and day out, following Scrum practices, trying to react gracefully to condescending “feedback” from toxic managers, and dealing with the constant threat of getting laid off. I even faced religious discrimination from one of my managers at Chase Bank. Despite the fact that said manager knew I couldn’t drive due to vision issues, he would still repeatedly corner me and ask me why I was coming back late from Friday prayer (I had to wait for an Uber or Lyft to arrive and take me back to work after the prayer was over.)

    I also want to take a more creative approach to the craft of software development. I don’t want to just bang out code and corresponding unit tests, and documentation to tie it all together; I want to transcend simply writing software by creating videos and prose around software development, and the competing interests that surround it. There are a lot of possiblities here: I could make tutorials in text or in video, create online courses for in-demand technologies, or talk about the state of the job market. I might try to do all of those things, to some extent. Most of all, one of my goals is simply to connect with other developers and professionals, so that we can all talk about our experiences and learn from one another, going forward into new successes without repeating mistakes from the past.

    We can also simply commiserate and support each other emotionally during hard times, like the present.

    This is all something I’m still learning how to do, obviously, but it’s great to already be seeing pretty cool results. I got five thousand views on a blog post in two days, despite still being new to WordPress. This also resulted in a great discussion taking place on a thread in the programming subreddit.

    Thanks for reading this brief post! If you like what you read and want to do something similar together, consider subscribing to this blog. There should be a big button at the top to do so, if you please!

    Also, if you’ve experienced anything similar in your career, I’d love to hear about it in the comments!

  • Docker Makes Setting Up PostgreSQL Super Easy!

    Hello, friends!

    I recently was working on a blog application in Adonis.js 6, and I ran into the issue of setting up a database. Originally, I set up the project with SQLite. It’s a very easy database solution, because the database is just a file in your project folder, with no database server or credentials required. However, while it can be used in production, I have seen that every tech job I’ve ever worked at used a heavier database, such as PostgreSQL, so I figured I would switch to that, just for the sake of good practice.

    I began to sweat a bit at the idea of having to install Postgres, then run it, then have to Google some weird issue, since sometimes some config file internal to Postgres has to be modified, depending on which operating system I’m on. So on and so forth.

    But then I remembered that Docker exists, and in fact, I have used Docker on the job to make quick work of setting up and connecting to existing databases! Especially the Postgres kind! 😀

    With this idea fresh in mind, I set out to search for how to use Docker to create a new Postgres database. The idea here is that the database will run inside a little container, which is basically sort of a mini-computer that runs on your system, isolated from the rest of the OS. Assuming you have Docker installed and running, you can connect to this database and use it for development purposes using these commands:

    docker pull postgres

    docker run --name devdb -e POSTGRES_PASSWORD=mysecretpassword -p 5432:5432 -d postgres

    To save you a bit of headache, I’ve explicitly specified port 5432, even though that’s the port PostgreSQL uses by default, as I was having port issues when trying to set up the database locally. Thanks for the tip, Claude! 😀

    Once you run these commands, you should see something like this in your Docker Desktop window:

    This means that your database is running, and you can connect to it and view its contents by supplying a database viewer like pgAdmin with the credentials in the command. Here’s what that looks like:

    Since the database is running locally, we just use localhost as the hostname. As per the Docker command I showed you earlier, the password is mysecretpassword. Don’t tell anyone!

    Common Pitfalls

    If you run into issues connecting to the database, make sure you entered the username, password, hostname, and port (5432) correctly. Also, make sure that Docker Desktop is running, and that the container some-postgres is running inside Docker, as well. Also, make it so that PostgreSQL is running only in Docker, and not somewhere else in your OS, as this can cause weird conflicts.

    I hope this article has helped you get set up with PostgreSQL and Docker! If you found this article helpful or interesting, please share it with your friends, and subscribe so you can see what I write in the future!

    Sources:

    https://www.docker.com/blog/how-to-use-the-postgres-docker-official-image

    https://stackoverflow.com/questions/5598517/find-the-host-name-and-port-using-psql-commands

  • I Hate Workaholics

    Something about software development attracts people who are really ambitious. Probably too ambitious, to the point of being obnoxious. Workaholics, if you will 🙂

    Anyone who has been in the workplace for more than a couple years, even less, probably knows someone that is way too enthusiastic about their work, to the point that it’s a bit irritating. This wouldn’t be that big of an issue if it didn’t muck things up for everyone in the office or what have you.

    The expectation becomes that if one person is putting in 60 hours of work a week (it usually doesn’t matter if the work they’re doing kind of sucks or creates more problems for other people), then why shouldn’t the rest of the team push just as hard? If anything, if said person is this inconsiderate of the team, it is likely that they will try to take credit for what other workers have done, in a selfish move to boost their own reputation. I’ve encountered this situation at Chase (on one of the more toxic teams I’ve ever worked in), where a coworker was trying to take credit for work me and another coworker actually did. He would have gotten away with it if said coworker didn’t have the backbone to go and tell the boss what was really happening.

    Never, ever work at Chase! But that’s its own whole post.

    I’ve since tried to cultivate a similar sort of courage and impatience with bullying and injustice in my own life. It takes a lot of self-awareness and work, because a lot of the people I looked up to, and still try to emulate when possible, are a lot more risk-averse than I had expected. Luckily, I also have some friends who have had some harsh experiences in life, and have still not lost their appetite for risk and retaining their independence at all costs. I keep these people close and cherish their advice.

    For all the stress workaholics cause themselves and others, I’m surprised people don’t talk about them more, so I figured I would add my two cents to the conversation. I personally am not impressed with them, because they could be doing a lot of good for the world, rather than just running around the corporate hamster wheel and diluting the amount of money they earn per hour. It’s painful to watch someone waste their effort and talent like that, especially in light of the fact that there are so many layoffs, even in big companies, which used to be considered much more stable and rewarding places to work.

    My blog has been taking off recently, and I’m getting thousands of views a day, even though this site has only been around for ten days (I imported many of my articles from my old Medium blog). If you think my blog and I have potential, please consider subscribing 🙂

    Also, I welcome any feedback you may have, and I’d love to hear your thoughts about workaholics or work in the comments!

  • Software Development Has Too Much Software In It

    Hello, friends!

    I’ve been thinking back on my career recently, which I’ve had plenty of time to do, considering that I am exploring creative outlets like blogging, and that I’m currently in between jobs. One thing that I’ve felt slowly creeping up on me is this strange-sounding idea that software development has too much software in it.

    As someone who talks a lot about software with friends and acquaintances, and engages heavily with technology both on and off the clock, this sounds like a very odd thing to say, but I think my thesis will become more clear as you read on.

    I originally got into software development because I wanted to learn more about how technology worked under the hood, and because I wanted to help contribute to open-source software however I could. Eventually, I made software development my profession, and I began to notice some peculiarities of writing software for a living in corporate environments. The complexity around tooling increased, obviously, as I started slinging code for a paycheck, sometimes for reasons that were more in the interest of the company than delivering exactly what the user needed.

    As an example, React or some other heavy client-side JavaScript framework are often asked for in job descriptions. I always found this a bit odd, as most places that asked for this kind of front-end didn’t have an apparent need for it. Arguably, they could solve their problems with server-side rendering of HTML and some light JavaScript, especially for internal applications that would probably not be used on mobile, anyway. This is supposedly done for standardization and ease of hiring, but I’m sure a developer who can tackle the task of learning and using React and its ecosystem effectively would easily be able to learn a lighter weight, simpler front-end library or framework

    Speaking of tools of the trade, it’s becoming well-known that software developers change jobs a lot, sometimes to increase compensation, and, as in my case, sometimes to escape a toxic workplace, or because contracts are becoming increasingly common, as opposed to full-time work, though those are whole separate blog post on their own. One of the big drawbacks to this is constantly having to learn new software architectures and environments. Even within two tech stacks that seem similar, such as two Spring Boot codebases, or especially JavaScript codebases, there is a lot of domain knowledge to learn, and more to the original point, the JavaScript ecosystem encourages you to piece your app together any way you like, rather than using frameworks. There’s enough things that can change between apps, like onboarding processes, database setup, VPNs, having to message a ton of different people to get permissions to access things, that I wish we could simplify and standardize the actual layout of the code, as an industry.

    I can see some possible benefits to this approach, but I’d much prefer that we just stick to frameworks, unless there’s a clear reason not to.

    Another drag on software and its developers is the overemphasis some places have on unit testing, even extending to unit tests in the UI! At one of the places I worked, they had terrific technical processes, and all my teammates were stellar, but the director of software development would endlessly insist on testing code, aiming for at least 85% code coverage. This made it so that I spent a small fraction of my time writing new code and actually delivering new functionality, and the majority of my time getting tests in place and working. Weirdly, the fact that we used a design library called Ant Design actually made some components impossible to test, so we would have to manually override the code coverage requirement sometimes.

    The sheer amount of time spent on unit testing easily nullifies whatever benefits were gained from doing so much of it in the first place. A big saving grace of this particular company, though, is that the QA team were great folks who really opened my eyes to what a pleasure it was to work with an actually good QA team!

    A big gripe I have with how software developers are often expected to operate is that they are often told what the requirements for the software are by a BA or some other liaison between them and the business, the developer is permitted to ask some arbitrary amount of questions (“not too many!”, “not too few!”), and then is basically told to shut up and do the work. Later, we are told that we should feel empowered to not just be software engineers, but to really, deeply care about the product, and to take ownership.

    The only problem is that we often aren’t really given ownership, but are nonetheless expected to behave like and care as much as owners. I’m aware that this issue isn’t just a problem that software developers have, and that all white-collar workers experience this alienation to some degree. It’s just that we are often told that the goal of software development is to create value for the business and its customers, but the business seems to be unwilling to let developers actually do that. To top if off, companies love to lay people off long before they can get truly familiar with the business itself, the domain, and the various codebases within.

    A final thing that comes to mind right now is the AI fatigue. AI tools constantly being released and improved, and the chatter around the AI tools themselves, as well as the constant ruckus around whether they’ll replace developers or not, is omnipresent and tiring. I wish people could just acknowledge that they are just another tool, and are not going to be the be-all, end-all of software development for a while yet. Unfortunately, misusing this particular tool won’t just mean that you can’t achieve your goal; you’ll also leave a trainwreck of a codebase in your wake.

    Please discuss in the comments anywhere where you think software has gone a tad overboard. I love the craft, but it is important to discuss how we can improve the tooling and day-to-day experience of our craft!

    I’m working on getting better on expressing myself through blog posts, so I can teach and encourage people on the Internet. Please leave any feedback or ideas for improvement you have, and subscribe! 🙂