Sometimes you need to spend the first 4 days of the week _feeling_ useless, to realize bright and early on Friday you actually were dumb this whole time.

Cheers 🥂

I know local dev is hard in a complex system, but if tooling prevents you from working for an entire day something is seriously wrong.

JavaScript: Default exports vs. named exports

Who gives a fuck, honestly? I used to think there was merit to one over the other, but I'm running out of steam to have these silly debates.

It's obvious that a lot of product managers need to take basic stats classes. Your metrics are pointless and lack direction. 🖕

What do you hate most about your current CI/CD setup at work?

Mine is that staging and production are released independently. If staging fails, it can still roll out to master. This scares me.

Splitting acceptance tests into categories of "blocking" and "non-blocking" just to allow CI to pass, is a waste of time and effort.

Check out the Changeling podcast series. Solid content about all aspects of working as an engineer.

Whiteboard the concept, tell a friend who hypes me up, never speak of it again.

Sorry Facebook recruiters, I don't think I can work for a company that has all the information that would likely prevent me from getting a job in the first place.

Start up leadership advice:

Believe your employees when they say they feel a certain way, or saw there's a problem. Fight the urge to defend what you're currently doing that may address it, and just hear them out.

Decided to start a new project tonight. A `brew upgrade && brew update` here, a software --install --restart` there. An hour from now I'll be ready for bed and have yet to punch a line of code.

Always best to start tomorrow anyway.

Am I the only one that negatively judges people who listen to podcasts or audio books while they write code?

"On a long enough timeline the survival rate for software drops to zero."

If we could get a full-time dev ops person for our org, I'd be so happy...

Do not, I repeat... DO NOT approve a pull request that you cannot adequately review. You're more to blame than the person who wrote the code in the first place when it fails.

The biggest distraction in all issue trackers is the hemorrhaging backlog of tickets that will _never_ be done, or aren't important yet.

This is why I just choose not to even bother opening it and let my PM close them out. :-)

How long are we going to let hardware advancements bail us out from writing shitty software?

As a front-end developer who has a firm grasp on web tooling, I still think the sheer amount of knowledge needed for dev-ops/deploy tools is staggering.

When a code sample is so obfuscated that it's almost better to leave it alone that to properly refactor it.

NoSQL database solutions are only useful for event streams. Nothing else. Wrestling with DynamoDB to try and filter a complex query is unnecessarily complex .

Suffering from our first service outage since I've been at my new job.

Guess when it happened? While we have TOO MANY projects going on.

When you have too many pots on the stove, you're bound to forget the smallest, most crucial detail.

I can't count how many times I've hated other people for writing MY blog posts.

If you come up with something you think is clever, write a short post about it, and don't hate yourself for not getting feedback.

A few weeks ago I finally got buy in to migrate our web team to GitLab for CI/CD.

All week GitLab has been having issues, pretty much rendering us unable to deploy anything with confidence.

Can't wait for _this_ to come up. haha

As silly as it sounds, but migrating our company's web application from Ember/JSON API --> React/GraphQL would be a pretty solid achievement.

We're almost to read-only feature parity at the moment with a single developers side time as a proof of concept.

I feel there aren't enough tutorials on "best practices" when it comes to combining server/client tooling in a monorepo.

Having done so this weekend, the tasks involved were:
* using graphql w/ express to serve requests and expose a "graphiql" ide instance
* differentiating build steps in prod vs. dev
* applying middleware in prod vs. dev
* working with a single heroku dyno

Still missing:
* hot reloading
* my general sense of direction

Why do product managers think their roadmaps/decisions are completely unrelated to our technical decisions? Information/transparency are key themes in the architecture process. In order to accept the risks, you must first understand them.

Nothing worse that watching a tech talk where the presenter is accidentally condescending.

It's definitely a "know your audience" situation, but it's cringe worthy when explaining a really valuable topic.

I really liked the Microsoft Zune. Thats it.

If I hear the word "platform" one more time...

What you mean are products that support varying use cases.

IMO, it's more difficult to build/support one application that supports 3 different user types, than it is to have 3 different well-scoped applications.

Thoughts?

Cleaning up after yourself if so damn important. Even your git repos:

# always be pruning
git fetch -p

# delete your merged branches
git branch --merged | grep -v master | xargs -n 1 git branch -d

# purge remote branches that are merged
git branch -r --merged | grep -v master | sed 's/origin\///' | xargs -n 1 git push --delete origin