Monthly Archives: January 2022

Beta Testing is Important

Software, ,

Remember the days when new software was released, but the only way to get it was by purchasing a disc from the company, then installing it yourself? (Goes right along with those fun AOL tones we used to have!)

When a company released a new software version “back in the day”, there was a lot more overhead. They had to really beta test their software update to make sure it all runs as it should. If there’s an error, then the customer gets mad. There wasn’t an easy way to push out a new software version just to fix that error.

Nowadays, companies will add some features and fix some errors, then do (if at all) little beta testing on those features and push them out over the internet. If there’s an error, it’s annoying for the customer, but not a big deal, as they know an update will come soon to fix it. It’s good in that customers can rely on these routine updates to fix bugs. At the same time, customers have become desensitized to these bugs. It’s just become part of some software, and personally, I think that sucks.

Take my friend, for example. His job revolves around using a specific software for broadcast graphics. He routinely finds bugs in their software. Unlike, say, a video game where an error can usually be overlooked, these bugs in software will crash programs and make his edits unreliable to his clients, because the software he needs has bugs. To make things worse, when they push out updates weekly, one bug will be fixed, but that fix will then crash other parts of the program. He quite literally has to save “good” versions of their software until he can find another one that seems to work well.

Software shouldn’t be this way. As much as I love the convenience of having routine updates available at our fingertips whenever we like, I do miss the days of software being mailed as a CD. I can be confident that the developers beta tested their software over and over again. I wish tech companies could keep this beta testing mentality, but merge it with today’s convenience.

One can dream!

Why Software Usability Heuristics are Important

UI

One aspect of software engineering I like is the User Interface. I think a product is only as good as the UI. If a user can’t figure it out, or the UI doesn’t touch functionality built into the code, then the product becomes less useful. Personally, I like simplicity for users, with the option of diving deeper into a UI if a user is more advanced or interested in it.

I would say I’m a more advance software user. I am always that person helping family members and friends setup software or edit software they’re using. I enjoy looking more into all the settings of a website so I can use it to the best of my abilities.

One thing that is important to me is the idea of being able to do something that the application “seems” like it should do. For example, if I’m using the github desktop app, I would expect it to be able to connect to my github account, link local repos with a master repo, review pull requests, etc. Anything I need for this type of project, I would expect that app to be able to do.

I’m a fairly new user of Slack. Before, I’ve never really had a need to use it, until I started working on my capstone project. The sponsor I am working with uses slack to communicate. Sounds good to me, I’ll join.

So far, so good. Up until I decided to venture off and build my own workspace, as they call it. Just to test it out and see what it could do. After playing around with it, I was ready to delete it. I’m using it through the slack app on my phone. I’m searching, and searching and searching some more, but I can’t find anything about workspace settings. This is something that I “feel” should be part of the app. Can I only create workspaces, but not delete them?!? That seems ridiculous.

Turn to Google. I look up how to delete a workspace. Finally find directions, but you have to do it through the Slack desktop app. Ok, weird, but sure. Download the app for my laptop. Finally get to the admin settings. Which, (face palm), takes me to a their website! Why did their own directions tell me to download the app, just to take me back to the same website??

This, to me, seems like a bad setup. The phone app should at least have some of the options on it to delete a workspace, and if not, have a link to that website I ended up at. Not directions to extra steps in the middle!

Rant over.

Anyways, my point is, an app should be able to do what you think it should. I know that’s a general statement, but I think it rings true. If you build something, make it all inclusive across all it’s apps, and if you can’t, at least try to cut down unnecessary steps. Keep it simple.

Add Some CSS to Your Workplace

Jobs

Having been in the workforce for 15 years now, I can tell you, without a doubt, different backgrounds are important. No, not different CSS color backgrounds (I prefer a nice navy blue in case you’re wondering), but diverse employee backgrounds.

Let me tell you about my current work, since that’s pretty much all I’ve written about so far anyways. I was a hire that was slightly off center. That is, I didn’t have the background they were looking for specifically. They wanted somebody who loves Linux and creating software that runs with very low level stuff, aka hardware. I had … 0 experience with that.

I applied anyways though because the company makes rack equipment for broadcasting companies. I had worked in broadcasting for a decade, so it seemed like the fit may be there, but from a different angle than they originally wanted.

Sure, it took a while longer than expected when training me, and perhaps I’m going down a road of software engineering that is different than what they hired for, but it’s been a great fit for both of us. They love asking questions about how a user would use this product.

None of the engineers on my team have worked in broadcasting. They built products they think broadcast professionals would want and use. Many times, they’ll throw in a bunch of functionality that simply isn’t going to be used, or stuff that may be used, but not in the way they’re thinking. That’s one of the reasons they love asking me questions.

For example, one of the teams builds a product that shows waveform and vector scopes (among many other things). One of the options was to adjust “stuff” to match what broadcast video is putting out. The item has great functionality, IF you have time to play with it. Broadcast engineers may have the time when setting this up, but they don’t look at it much after that. Primarily broadcast directors would use this in everyday operation. That’s the position I worked in. I was able to talk with the team about how I used items like this. While all the functionality is great, I don’t look at any of it while directing a broadcast. I need two or three specific things that are quick and easy to get to, that’s all I need. We were able to put in some design comments for the next generation of that product, and that felt good being about to contribute to the product based solely on my background.

I wish our teams had more diverse backgrounds. People coming in from a complete outsiders perspective give the best suggestions, because it’s all new to them. I highly encourage managers to develop diverse teams and to not be afraid of bringing in talent with backgrounds that may not seem like a match at first. It’s worked for my team already!

The Dreaded Technical Interview

Jobs, ,

What’s the worst thing about looking for a job in software engineering? In my opinion, that would be the technical interview.

It’s easy enough to talk about projects you’ve worked on or how you would be a good addition to the company, but it’s another thing to be able to show off coding skills on the spot, especially for a junior engineer.

I’ve completed (completed may be a strong word) several technical interviews. Each one a little different than the last. The worst was for a gaming company in town. I had twenty minutes to code, using C++, a problem they gave me. While normally this would be no big deal, my heart started racing when I knew I only had the 20 minutes AND two people on the zoom call were watching my every keystroke. That was horrible. Let’s just say, I did not hear back after that.

Other technical interviews are a little less stress based. I applied for a job at Amazon and went through multiple rounds of technical interviews. These were all timed as well, but didn’t have somebody watching me. It also consisted of multiple smaller exercises, and they mainly wanted to see what thoughts I could apply to these problems, if I didn’t finish it. I did well, was invited to do some in-person interviews, but ended up not pursuing any further after that because of a different job opportunity.

I think my favorite (favorite, yet again perhaps a strong word) technical interview was for my current company. There was no coding specifically, the hiring manager even mentioned that he can look at my portfolio to figure out my coding ability. We talked concepts. The manger provided different scenarios that fictional users may encounter. He wanted to see how I approached it from a high-level view. For example, one scenario was a new parking garage keeping track of cars that come in and go. The prompt was specifically vague, in order to see where I’d go with it. They’re looking to see if people create user stories, ask for more details, see prompt for what needs to be fixed, find out what external pressures there are, etc. The idea was to see how I would handle a new project and if I could ask the right questions while setting up something that the user actually wants, not just what the user says they want.

I liked this idea a lot more than the usual “here’s a problem, code it to make it work”. I think giving a more high-level view of a problem and seeing how somebody would handle it is more of an insight to a candidate than seeing if they can make a small problem work under pressure.

Let’s just say, I’m happy to be working for that hiring manager now. He clearly appreciates different views that his team members bring to the table. It creates an interestingly diverse team all working towards the same goal.

I got the job! Now what?

Jobs, ,

Have you ever started a new job and had no idea where to begin? I’ve had that feeling, 8 times specifically since I first graduated college in 2010. Sometimes I can blend into the position and soon run with it. Other times I feel lost for months. It may be worrisome, but let me tell you, it always gets easier.

I’ve worked in the local news industry for 12 years, starting as a photographer’s intern, later trying out producing, then finding my niche in broadcast directing.

Remember this scene from Star Wars?

Yeah? Well that “control board” is called a switcher. We use it (or automate as of recent) for directing local news. When I first became a director, that board was intimidating! There’s buttons, there’s menus, there’s external devices. There’s anything and everything Grand Moff Tarkin would want when blowing up planets. As a new director, I thought I’d never figure it out. Things take time though, and sure enough, I became an expert. So much so that I was teaching others the intricacies of the switcher just a couple years later.

Fast forward to today. I officially switched careers and landed my first software engineering job with a company that makes broadcast equipment (how fortuitous!). The first two weeks I spent just playing around with the equipment, not even looking at code. That was challenging enough. Then they gave me the keys to the (source code) kingdom. There’s millions of lines of code, most of it legacy. By legacy, I mean there are chunks of it they still use that are dated in the ’90’s.

I’ve been here nearly 5 months, and I’ve barely scratched the surface. Many times I still feel overwhelmed. I have to remember from my experience with new jobs though, it gets better. It’ll take some time to get used to developing software and the intricacies it entails.

If I can provide anybody in similar situations or for many students looking for their first job in a new industry, this is what I’d say: Always ask questions! Find those people at your new job you trust and pick their brain. You’d be surprised how many people like to share their knowledge with junior developers. Embrace code reviews and do your best evaluating pull requests. Be open to trying new technologies and always push to do things outside of your comfort zone. Most likely, we won’t be in this same job 5 years from now. Develop skills in the real world that are useful. Don’t lump yourself into coding in just one language.

Sometimes new jobs are fun, most of the time they are terrifying. I definitely get a sense of imposter syndrome with some positions. Always remember though, they hired you for a reason!