What are the most important qualities you look for when hiring new devs? What are the biggest warning signs for you? We're gearing up for interviewing devs in the near future so I figured I'd ask the devRant think tank its thoughts on the matter.

Thanks Google

*coding, furiously, to sweet tunes*

*awesome new song comes on I haven't heard before*

*30 seconds in, saves to playlist*

*Song continues playing*

*....Removes from playlist*

Just received a job résumé for a software engineer position. The very first skill listed:

MS Word.

People here working your own business or side hustle:

1) How long have you been doing it?

2) What kind of tech stack do you use in your product(s)?

3) Are you happy with your business endeavor or has the grass become greener elsewhere?

4) What is the most important thing you have learned from it that you wish you knew when you began?

Apple just announced a new 6k monitor. The stand for it is NOT included and will cost $1000.

This snapshot of the presentation is meme-worthy.

...People will still buy it.

Unnamed SQL constraints are the devil.

While watching season 2 of Star Trek Discovery, it was nice to learn SQL is alive and well in the 23rd century. Also, that there are still idiots that don't defend against injection on a warp-capable spaceship with transporter technology.

Super important prospective client: Yes but can your software application do that thing?

Me: Yes, yes it can do that thing.

Prospective: Great, fantastic thank you please take my money.

Me: Awesome.

Me: *runs away to implement that thing*

Please have my tombstone read "sales-oriented software" as cause of death.

Around 11:30pm I honestly thought I was about done, but a series of production issues has kept me up until 4:30am. Solving one revealed another, and so on.

Finally, all is quiet.

Goodnight World.

First, realize that trying to accurately estimate how much time something is going to take is akin to accurately predicting the future and that people who ask you to do it are stupid. Then realize that sales-oriented deadlines are the source of all that is evil. Then shift away from sales oriented software. Instead focus on selling existing features and new features on the roadmap have no deadlines, they're done when they're done. Then realize almost no workplace will let you truly do that because chasing the sale is all that matters despite the latest buzz word rhetoric. Then estimate enough buffer to give you a reasonable time to complete it without calling your abilities into question. Then finish it faster so you score points with management, but not every time because then they'll begin to expect it. Now you have leveled up in mind games, an unfortunate but necessary tool in the tool belt. Then hate on sales oriented software some more, rinse and repeat.

To me, writing authorization code for securing APIs is like having to fold an enormous pile of laundry and actually putting it all away afterward. It needs to be done but I'm not going to enjoy it.

Time for a soap box rant.

I just found this in one of our projects. I've simplified the example to make it more anonymous.

When I see code like this it automatically means there is a lack of attention to enumerations and/or understanding of what they are.

One may argue that in a certain execution of code it's a minor performance hit and therefore insignificant. It's still a performance hit. Furthermore, it takes even less time to do it the right way than it does to do it the wrong way.

Every one of these lines will enumerate the list from the beginning to try and find that one element you're interested in. Big O notation, people.

Throw that crap into a dictionary or hashset or similarly applicable data structure with direct reads at the beginning of your logic so that it only gets enumerated ONCE when the data structure instance is created. Then access it however many times you want.

Soap box rant over.

Dropped out to grow a business I co-founded. Respect to all those that finished. I was already working a six figure salary as a software engineer before I even started at a university. I decided to attend though to have a more complete resume. One day a professor explained that we could look forward to doing really "advanced concepts" like web services OUR SENIOR YEAR. That was already daily life for me. Our business was starting to grow quickly and it needed more and more of my time. I chose the business and for me, that was the correct choice.

Another VERY satisfying commit.

Test A succeeds when run solo. Test A fails when run in conjunction with Test B. Obviously, some kind of messy state that isn't isolated per test.

I realize what it is, so I add a new feature to address it.

Test still fails, it had nothing to do with that.

I finally realize what it was. One liner fix.

Yay for a new (useless?) feature that isn't getting backed out.

Omg, delegation to others feels like the last, most difficult skill to master. Letting go can be so hard.

Patience, me. Patience.

Client just informed our support that they solved their own forgotten password problem by clicking the "forgot password" button in our app. They say they are now awaiting the email with the password recovery details.

One problem: we don't have a forgot password button in our app.

There will be much caffeine consumed today.

Lots of hate towards Microsoft, and they go and do something like this:

https://blogs.msdn.microsoft.com/do...

I'm excited for these features. With existing .NET Core you can compile console apps natively to Windows/MacOS/Linux. WPF and WinForms soon making it to .NET Core will bring the ability to compile native GUI apps too.

Oh, and .NET Core is all open source. It's a beautiful, beautiful thing.

May IE burn in hell.

One time I was trying to get something positioned properly, and it worked on all browsers except IE. There was this little gap between two divs and I couldn't get rid of it. In desperation after hours of troubleshooting and lots of CSS attempts with no solution, I removed the whitespace from between the two divs in the HTML:

<div>...</div>
<div>...</div>

to:

<div>...</div><div>...</div>

And voila! No more gap when looking at the rendered page.

FML I hate you, IE.

One of our existing clients who used to pay for two of our products but now only pays for one just called us. The one he canceled is a loss prevention product that tracks internal theft in stores. He canceled it because he didn't feel it was worth it.

Now, he's calling us from a police station because he's trying to press charges against one of his managers because they were presumably stealing from him.

"Hey I need to know how many times this person stole from me over the last few months and I need to know it now because I'm at the police station."

With just a few clicks that would be an easy figure to retrieve for him had he not canceled our product.

My stance is he can get lost. I don't even think he sees the irony of canceling because "it isn't worth it" and then "asap" needing the data that the "worthless" product provides. Of course, he wants it without reactivating the subscription.

Unbelievable.

With luck like this I'll be buying a lottery ticket next.

The same thing I do every year, Pinky.

Try to take over the world!

Not exactly vacation, but there was this nice-to-have feature in our application that I coded up in the hospital after my wife gave birth to our son. I wrote it during the downtime while they were both sleeping.

When I hit the endpoint from Postman it works. When I hit the endpoint from my application that pushes data to the endpoint it doesn't work, returning a 404 status code. I KNOW the endpoint is there and operational and that both Postman and my application have the same endpoint configured, letter for letter.

So lost. So confused. What the hell is going on.

I decide to install Fiddler to monitor the traffic to see if I can see anything helpful.

I initiate the request again from the application and immediately see that the request size is huge. BAM. It immediately hits me, the payload to the endpoint is too big and the server is "rejecting" it with a 404. I post a smaller request with the application and it works fine.

Yay, saved by Fiddler.

Why does the endpoint default to 404 in such scenarios. The definition of 404: "the client was able to communicate with a given server, but the server could not find what was requested"

In my case, the 404 returned was a red herring. I understand that the substatus code gives more information on why the 404 was returned, in my case the request size being too big, but 404 in general feels like the wrong status code to return because the endpoint IS there. It made me troubleshoot the wrong thing.

Thanks, IIS.

Satisfying commit.

Not a coding test, but:

Them: So you are interviewing for a programmer opening. Do you like programming?

Me: yes.

Them: do you make logos?

Me: ...I can...?

Them: good because you won't always be writing code here.

Me: I'm out.

Hours lost.

Visual Studio test adapter was failing out during the discover phase of the tests with a stack overflow exception, but that's all the information it gave me. The tests simply would not run.

Hunting through the code line by line, I eventually find this.

WHY IS THIS ALLOWED TO COMPILE

At my first job, I got tired of having to type a user name and password every time I debugged the web application. Thinking I was clever, I put in a hack so that if you launched the application with the query string "?user=Administrator" it would log you in as the administrator. So much typing saved!

A couple days after the next release, I realized it shipped like that. In absolute horror, I walked into my boss' office, closed the door, and told him the tale of my mistake.

He just looked back at me, and after a moment or two said, "Loose lips sink ships."

And that was it.