This class adheres to the single responsibility principle: it is singularly responsible for the entire application.

If a feature no one uses has a bug in it, is it possible for that bug to be flagged as critical?

Next step is management

Typical Monday where I log in to find an alarming amount of stupid to deal with.

Best dev experience was coding one of my favorite board games. I started it early on in 2016, and while it isn't completely do finished (AI needs work and tweaks to the UI), it is functional for hot seat play.

I started doing it because I wanted to make a game and learn some things I didn't know, specifically I was interested in making AIs with different strategies. While I set out to learn this, I've learned so much more along the way.

I'm still really happy when I get to work on it, and having something to show people (that they can actually play!) is a great feeling.

What I would define as a critical bug:
- System doesn't respond
- Functionality is broken
- Client data is all wrong

What QA defines as a critical bug:
- Typo on this page in the QA environment

Any meeting that's before 10 a.m.

I played a lot of Command & Conquer when I was younger, and I remember going through the files for C&C: Red Alert. I found one that had all the units names and properties, and wondered what happened if I changed a value. So I changed grenadiers attack speed to something ridiculously fast, and found that it actually changed it in the game!

The light bulb went off in my head, and I then created new units:
- Albert Einstein that shot electricity
- Attack dogs that launched missiles

Granted the animations didn't exist for these so it defaulted to playing their death animations when attacking, which was amusing.

That was the ah-ha moment for me that lead me to pursue programming. It was just so much fun!

Just got a message from a recruiter about an opportunity at a FinTech company. Does this mean financial tech? Please tell me this isn't a thing.

Be humble. Nobody knows everything.

Keep learning: read books, take Pluralsight courses, go to meetups.

Write unit tests for your code. No really! Write unit tests for your code!

Learn what the SOLID principles are.

Your job does not define who you are, you define who you are.

A controller action taking a string input and directly accessing the file system with it, returning the file.

Commented out code.
The anti-comment.

Imposter syndrome

Me: We really need to improve our unit test coverage.
Team/Boss: <sarcasm> Haha yeah.
Production Bug: I'm doing something nasty to a client, because a dev broke something but no test coverage.
Boss: How could we have prevented this?!

Working from home.

QA: Hey I found a bug.
Me: Okay, can you log the bug and assign to me?
QA: <audible sigh> sure

UI bug is found to only occur in Firefox.
Director sends mass email telling dev & qa to only test using IE11.

Boss: I'm thinking something like a facebook wall...

For a site where people access once, download what they need, and never come back.

Controllers are nice.
Controllers are fun.
But please don't throw all
Of the apps code into one.

When explaining unit testing:

"We tried but every time someone changes something in the database all the tests fail."

*facepalm*

Log into work at 9 am to see a meeting scheduled for 7 am, sent at 6 am.

If you are going to tell me you develop using TDD, it's a good idea to actually have tests in your test project.

Not a rant but it's Friday and thought people could use a laugh.

When I was a teen we used AOL and for those who don't know, it was a test of patience to log on. It had to dial in, actually connect, and then you hoped it wouldn't disconnect for whatever reason. Just getting it to connect would take 30 min or more some days. After you were logged in you would get an audio of *Ding Ding*, followed by "Welcome!" and if you had email, "You've got mail!"

So, I decided to play a prank on my dad by swapping the Welcome sound file with the Goodbye sound file. He was waiting for a long time to connect, getting so frustrated. Then it finally does and he hears:

*Ding Ding*
"Goodbye!"

And loses it. Then he notices he is still online and calms down, confused.

I told him about it later but my brother and I got a good laugh out of it.

When asked what the spec is, or any overall vision for the project:

We are building the ship while sailing.

Comments throughout code with things like "changed to fix bug #". And commented out code all over.

We have source control, why the hell are you doing this?

The build breaks due to a failing unit tests, and what does the dev do?

Comment them out.
Commit.

Lead: "We write SOLID code"
Me: *opens a controller file*
Controller: "I'm 8000 lines long and hell yeah I'll access the database and file system directly!"