DEV Community: matt kocaj

What Junior Devs Need To Know About Complexity

matt kocaj — Fri, 28 Jul 2023 04:22:16 +0000

I don't remember how but I stumbled onto grugbrain.dev last week.

It's gold.

I could literally end this post on the line above. But I did wonder about how junior devs might find this content. I personally find it to be amazingly written. It's just my kind of comedy with a dash of WAKE THE FUK UP NEO! 😆 But I'm not exactly sure whether a green engineer will understand much of it and gain the most value possible. So I wanted to add some of my thoughts. The following is just a commentary. I don't want to subtract anything at all, but if I'm lucky, maybe unpack things for a less-seasoned audience.

Let's start with this section --

The Eternal Enemy: Complexity

apex predator of grug is complexity

Complexity is quite literally the biggest threat to any software engineer and all of software engineering. Why? Well I'll try to uncover that below and close with a few of my own thoughts at the end.

complexity bad

Don't misunderstand this point. It's worth repeating.

I actually struggled to agree with this a little and it was largely "semantics". But semantics are important because they convey meaning. Don't let someone criticise you because you're "getting hung up on semantics" - people who get hung up on semantics usually care about clarity. This might mean that they want to understand things deeply. Don't miss an opportunity to work with someone like this.

There is this narrative in the software engineering community that roughly tries to draw a distinction between complexity and that which is complicated. That alone deserves a post all on it's own, but the short version for me is that I'm now ok with allowing them to exist in the same container. There might be an occasional reason why complexity is necessary. This is usually the hang up - how can you avoid something that you need? Now I wonder if this is just another problem solving activity.

If you think you truly need complexity n, then try to design it out. Try to reduce n or delete it altogether. Remember, "the best part is no part".

say again:

complexity very bad

you say now:

complexity very, very bad

Say it out loud even. If the guy across the desk from you gives you one of those "what a weirdo" looks, then link them to this post. Just be like "he told me too" while pointing at your screen.

given choice between complexity or one on one against t-rex, grug take t-rex: at least grug see t-rex

The subtlety here is that complexity can often be hard to recognise. This is especially terrifying when you realise that complexity is kinda glorified in our industry, particularly among younger engineers who are out to prove themselves. It's like lifting at the gym: if you can lift something heavy, you're cool right? Well, if you can build something hard, or solve a hard problem, or a complex problem, then you're cool right? Just get your flex on and show the world how great you are...?? 🤷‍♂️ I'm not saying that some engineers try to hide complexity on purpose. But there is a large cultural incentive to add it and because it hides in dark corners and is hard to see, its a very real problem.

Training alone won't be enough to help you spot complexity. It comes mostly with time. But one signal is pain. If something feels harder than it should, then maybe it's too complex. Of course this is pretty subjective and a "gut feel" kind of thing. But soon you will learn to notice the sensation. Listen to it. Search your peelings.

complexity is spirit demon that enter codebase through well-meaning but ultimately very clubbable non grug-brain developers and project managers who not fear complexity spirit demon or even know about sometime

I could be wrong, but I suspect that "non grug-brain developers" are actually "big brained developers" as referenced elsewhere in the article. "non grug-brain developers" may also refer to junior or less-seasoned engineers. Or maybe devs that don't share some of Grug's qualities, like humility. Ego is certainly a common trait in the software engineering industry. "It's ok to be wrong" is an important life lesson. But applying this early in your SWE career will give you a significant advantage.

As I mentioned earlier, complexity is popular in our industry at times. This may be part of the reason why its not respected or even feared. Fear is important - it keeps you from falling off the edge of the cliff. It's a signal about danger. Complexity == danger. If an engineer has a hard time properly respecting complexity then a non-technical person like a project manager may find it harder still.

Keep in mind that as a new engineer, you won't know how to spot complexity at times. You often need a wide variety of experiences to see how complexity manifests in different contexts to attribute patterns to its appearance. There are few simple ways around this. You will learn over time. Some developers can't see it [yet]. There's no shame in this.

one day code base understandable and grug can get work done, everything good!

next day impossible: complexity demon spirit has entered code and very dangerous situation!

This is obviously an exaggeration, but complexity can lie in wait so well that it can appear to jump out of nowhere. It's the forrest for the trees thing. Or simply that moment when you take a step back because you've been in the weeds on a particular thing for so long that you don't see what's happened at a macro scale.

The other thing to call out here is that once complexity has taken hold, it can literally grind productivity to a halt; or at least make changes extremely slow. Often this comes about purely from the next developers inability to understand whats going on easily. Most engineers don't write code. That's not what we do for work. A programmers primary time sink is reading code, not writing it. So it's critical that you as a developer can help another developer read and understand what's going on. That's not just scoped to your function or file, but the application and system as a whole. Complexity will destroy this ability to read and understand. And since engineers are typically clever people, they will work around complexity at times not even realising that said workarounds are increasing the level of complexity! This doesn't seem wrong at the time because that developer has a good understanding in their head. But the next guy? Good fuken luck!

EDIT: One thing I didn't really consider properly is how "exponential" this can grow. I guess this makes sense as to why it can feel like it happens overnight. I want to give this more thought. Grug recommends: Complexity Budget

grug no able see complexity demon, but grug sense presence in code base

Even experienced engineers can't often put their finger on the exact source or target of the complexity. Sometimes it's a sense or a gut feeling. I've seen developers cringe, or curl up their face. It's an instinct that you develop over time and various projects.

demon complexity spirit mocking him make change here break unrelated thing there what!?! mock mock mock ha ha so funny grug love programming and not becoming shiney rock speculator like grug senior advise

This is an analogy to the "complexity spirit demon" having an intelligence of its own. It's genuinely hard to counter this thought if I'm honest. I joke a lot, but here I am very serious: given that the complexity is almost always sourced from another person, I don't think its a stretch to describe the "demon" as an intelligent entity. Think I'm crazy? Well, if you wanna go deep on this then consider that the universe might actually have a tendency to entropy or disorder. And we humans facilitate this. So every line of code that's added is in fact just a little more potential for complexity and peer-induced pain. This is part of the reason why experienced developers love deleting code so much. Sometimes you just don't know where the disease is and you wanna rip large chunks out in the desperate hope that your artillery strikes will land on the enemy.

And other times, you just wanna start again from scratch.

Have you ever seen a senior engineer crying in the corner?

My money is on complexity.

I don't think Grug has chosen the word 'demon' lightly.

I'm not entirely clear on what "shiney rock speculator like grug senior advise" means but I suspect its something to do with the fact that getting paid well, often doesn't counter the pain that one can endure at the hands of complexity. I actually love software engineering as a creative pursuit all on its own. Sure I also need to feed my family but there are some things in this world that will threaten even the intrinsic love you hold for something: complexity is that to software engineering for many of my seasoned friends and colleagues.

club not work on demon spirit complexity and bad idea actually hit developer who let spirit in with club: sometimes grug himself!

Sometimes you can't simply attack the complexity directly. I've seen this time and time again. We engineers love to make cool stuff. Sadly tho, most of the "cool" things we build are not necessary, or are unnecessarily complex. This is where attacking the complexity becomes attacking another person. This then becomes a human relationship problem. And if you you thought being a programmer meant you could escape human relationship problems: you'd be wrong!

sadly, often grug himself

It wouldn't be the first time I built something in an app and then later ripped it out myself due to complexity. It hurts and is humbling. So do it often! That's how you grow.

so grug say again and say often: complexity very, very bad

The point can't be drilled hard enough. This is why I wanted to annotate the article with my thoughts. I'm sure I'll be commenting on this theme for the rest of my career, probably at the pain of my grandchildren when I'm old and can't remember what I said 10 seconds ago. Hi guys! ❤️

If you're new to software engineering, and you can't see how all this fits in to your life, work or just the space in general then remember this:

Complexity is real and it's hunting you right now. But as an inexperienced engineer, you're vulnerable to its guile and tricks. It's going to tempt you with shiny packages and tools. It's going to bend your mind and titillate your taste buds at conferences and with awesome presentations. Soon you will think you know more than someone else and next thing you know, you're writing some "cool" code that will impress all of your peers. It has you now. You're its bitch!

The best counter to complexity as a new engineer is humility and open mindedness. I wish I applied more when I was younger and the more experienced I get, the more I try to focus on these things. Learn from clever peers. Learn from experienced engineers.

May The Force be with you. 🙏

Thank you to JakeGPT, Ruegen and Grug himself for edits, comments and feedback.

Originally posted to hammerproject.com

Key learnings after 10h diving into Lambda, js and Github Actions

matt kocaj — Fri, 06 Jan 2023 08:08:05 +0000

I recently heard that you can learn almost anything if you spend 20h of unbroken, concentrated effort. Of course you won't become an expert and everyone has to pee, so the statement comes with some obvious caveats. But I thought I would try something new and dump most of a weekend onto a small project.

The Story

I've been suffering from a very not-painful first-world problem lately. 😋 When I get out of my car and go into the house I usually have my hands full and I want to lock the car behind me. To overcome this, I would like to ask Siri to lock the car instead of opening the app and tapping it. I've discovered that the Tesla app needs to be open for the car to take commands via Siri. This won't help when the phone is in my pocket locked and all I have to access "hands free" is the Apple Watch. So I asked myself

Can I create a web endpoint that I can call with Shortcuts which can be invoked using Siri?

Turns out I can. So I set out to create an endpoint that is long enough to be "secure" so that I could write a simple Shortcut that I could use with Siri from my Apple Watch while my hands were full. Something like this:

aws.thingy.com/lambda/lock-car?secure-token=reallylongassrandomstringthatyoucantguesssothisiskindasecure

After knocking out a README with a set of goals and a list of TODOs to check off as I made progress, I spent about 10 hours over a weekend trying to get something to work. I used serverless for making Lambda easier, Github Actions for the deploy pipeline and store my credentials; and sadly I rolled my own access_token refresh logic because I couldn't find a helper that just did that for me! wtf!?

I now have a Shortcut that works using Siri; a Lambda that can refresh it's own token and a reliable way to lock my Tesla without my hands. It even speaks the text response from the HTTP call: "car is locked" which is kinda satisfying.

Key Takeaways for Me

serverless is amazing! Sure it's the first thing I found. But it made it super easy to set up my js project locally, run it locally and deploy it from the command line. I can't understate the importance of a fast feedback cycle. Since I lack a lot of debugging experience with vscode/ts/js it is important that I can console.log easily and run locally to try/fail/repeat.

Lambdas are pretty quick. Cold starts from the Shortcuts app can be about 5s end-to-end and this includes a token refresh. When the lambda is warm and using the new access_token, it can be as quick as ~1100ms according to CloudWatch.

The js was pretty straightforward and I'm no js/ts expert. I was cautious and used callbacks instead of Promises. So I should try that next time. 😋
Actions start and run really fast! Having come from the "old days" where pipelines were <10m to large microservices codebases where pipelines are back to running ~30m, it is super refreshing to have a pipeline which is not only short in terms of duration (1-2m total) but kicks off within a couple of seconds of my pushing my code to master. 🥰
I didn't feel the need to use Parameter Store as the credentials in Secrets are one way and serverless hides them in the logs when mapping params (or is it actually Github doing this?). I accept that for a "professional" application, I wouldn't do it this way, but it's fine given the context. Feel free to tell me why I'm wrong. 😋
I wanted to create a "revocation" call to pair with this automation but I changed my mind on that. Mostly because the commonly accepted approach with an integration platform with API credentials is to reset the password on the primary account and this invalidates all derived keys. I tested this and it works so I think that's fine for now. Yes, I have a production key stored in Github and as an ENV var in AWS which is as good as my Tesla password, but the attack surface is pretty limited I think. There are other apps which ask you to authenticate, and then they persist refresh tokens. I don't think my solution is worse or creates more risk than those.

Whats Next?

Here are just some random thoughts about things I might want to change or improve:

setting up a new Shortcut to start charging the car
how will it be structured in Lambda?
how can I share code like the token refresh logic between two functions?

I hope you found this interesting. I'm constantly amazed at what can be accomplished if you set your mind to a clear goal.

Originally posted on hammerproject.com

Smashing Entropy

matt kocaj — Thu, 17 Nov 2022 17:47:38 +0000

tl;dr

Entropy will destroy your business and your product if you do nothing. So in order to prevent this doomed future you will need to fight it.
Fighting entropy requires an aggressive approach to keeping things small and getting feedback fast.
However you will encounter resistance in the form of people. Without a smart person in a powerful position with a big hammer, you may only have moderate success.

What is Entropy?

Entropy is often described as the measure of disorder or the loss of information. In the case of information and software systems you can think of information "loss" as the signal to noise ratio (SNR). Values > 1 mean more signal than noise.

You don't have to change the quantity of the signal for the SNR to drop. You only need to increase the noise. At the beginning, a small MVP or a simple product might gain traction because it's small, nimble, and solving a problem really well. It's fast and clean and only does what it absolutely needs to. The business around this product is also lightweight, mirroring the elements of the application architecture: simple, easy to understand, fast and agile. But noise is introduced in terms of process and systems. Code is added as scale increases. The absolutely critical elements that the product and business require to run are the "signal". The signal grows more and more slowly. The noise grows more and more quickly. The SNR drops. This noise is entropy. You need to fight entropy.

I'm not talking about Technical Debt here. Much has been written on this subject. But I will say that Technical Debt is a form of entropy. Once you have a strategy to combat entropy you also solve for Technical Debt.

Entropy is the gravitational like force which pulls you, your team and your whole company in the direction of "more". It’s your job to extract, disassemble, dissect and prune back this “more” to get to the signal: the critical and essential parts you need to ship the next iteration and validate what you think you know.

How Do I Squish This Thing?

Apply Elon's 5 Steps To Design.

The following video clip captures Elon Musk enumerating his 5 step design methodology. The 5 steps listed below are not terse in this interview clip. They're interleaved between highly specific examples, much of which relates to rockets at SpaceX and cars at Tesla. Stick it out: the "concrete example" nature of the conversation really drives home the value of each step and why the order of the steps is critical.

source: Starbase Tour with Elon Musk PART 1 // Summer 2021

Elon's Five Steps To Design

Make the requirements less dumb.
- Each requirement/constraint must have a person and not a department.
- That person must own the requirement.
- You can't challenge a requirement if it's a person who no longer works at the company or if it's a department which isn't a person.
Delete the part or process.
- "if you're not adding things back at least 10% of the time, you're not deleting enough"
Simplify or optimise.
- "possibly the most common error of a smart engineer is to optimise a thing that should not exist"
Accelerate cycle time.
Automate.

If these steps make intuitive sense to you then you're probably a good agent for change. The very next thing you might realise however is that you don't have the power to influence any/all of this. This is where you need the hammer.

So What Is The Key Ingredient?

Andrej Karpathy made this statement in a recent interview:

I do think you need someone in a powerful position with a big hammer, like Elon...
If no one has a big enough hammer, everything turns into committees, democracy within the company, process, talking to stakeholders, decision making... everything just crumbles.
If you have a big person who is also really smart and has a big hammer, things move quickly.

Here's a quick example of how things can be "unstuck" to move more quickly. Start small like this:

Not everything needs to be a committee. A quorum of two in a group of smart and experienced people is usually enough to make low impact decisions. Optimise for forward momentum.

Starting small is good. But if you need revolutionary change, or if your problems are so great or so systemic; or if the rate of progress is too slow, then you might need the big hammer.

Who is that person in your company with the powerful position and the big hammer?

If it's not you, then can you find that person?

Can you show them this article to test their appetite for moving fast and making progress?

And if there is no one in this role, can you move yourself into it?

"Challenge accepted!" I hear you say?

Good luck! 💪

Thank you to Hamish, Cam, Michael, Ryan, Ed, Colin, and Duane for reading drafts and providing valuable feedback. 🙏

If you think it’s about time you had someone like this in your organisation, then hit me up. I might know someone 😉

This article was originally posted on hammerproject.com but feel free to discuss on HN or LinkedIn

Effective teams: When you’re an emotionally challenged developer

matt kocaj — Tue, 11 Jun 2019 03:30:09 +0000

I am an emotionally challenged developer!

I’m not the most socially aware person in the world. I can be abrasive, totalitarian, “direct”, antagonistic, and even a plain ol’ asshole sometimes. Am I a bad person? No! Do people like me? Apparently - they invite me to lunch, drinks after work, ask how I am and generally want to be around me. I’m just saying that I have my strengths and weaknesses as everyone does. It’s important to be honest about these and if you’re confident enough to admit it to yourself, then try sharing it with a colleague - you’ll be amazed at the strength it can add to your working environment.

So here are my three tips for being more effective in a team. These are especially useful to those who might find it harder to integrate into a team in a non-technical capacity –

Be Kind

Talk with your peers.
Join them for lunch.
Buy them coffees.
Let them buy you coffees (especially important for those of us who struggle with receiving gifts)!
Be patient during discussions, even when things are frustrating you.
Remember you don’t always need to win. Teamwork is about compromise just like every human relationship is. And for clarity: working in a software team is a collection of human relationships. Yes, you do “do ships”!
Try to participate as best you can. If you’re introverted, then it’s important to share your ideas and opinions occasionally. Others need to know you care if only a little. Please try to join in.
And always remember: don’t interrupt others! It’s so rude. Respect is a cornerstone of human interaction. If you cut others off a lot or talk over them, then please begin to listen to yourself. Listen to others first who do it if you can’t hear it from your own mouth yet. It’s important to chip away at this one. And if you do manage to bring this under control, you’re not going to have others copy you because you’ve suddenly started to be polite. But that’s ok.

Be Vulnerable

Share something about yourself with your peers. It doesn’t have to be in a group, it might be just one person you seem to trust a little. It doesn’t have to be “my marriage is failing” or “my pop just died” but it should be something that reveals a little about you and that you don’t “have it all together”.
Show others you’re not perfect. “Nice catch” - on a Pull Request; or “my goof! I’ll fix the broken build”. In other words, it’s ok to show that you make mistakes. These are somewhat unnecessary from a pure knowledge transfer point of view, but we’re not dealing with machines here. People want to know that they can identify with you, that you’re human, imperfect and fallible like they are. It helps you to be more likable, and you do want to be likable.
Ask for advice (even if you need to fake it a little). Find a way to have the junior dev help you even if you consider yourself far more experienced. It will not only boost their confidence but help them to trust you more. This is especially handy when you need an extra ally when you propose that massive refactoring you’re sure will reduce technical debt.

Give Something Back

Your time - pair with someone; offer to review more code; take more time to explain your passions, points of view and reasons for the preferences you’re so driven about.
Buy coffee or donuts (or vegan “power balls” that are free of gluten and flavor). If you don’t have money, write a post-it for a peer thanking them for their help yesterday. Just don’t make a show of it to others.
Shout folks a lift to the restaurant for lunch; pick up a colleague walking from the bus stop because you have the car today; offer to carry their gear to that meeting when you can see their hands are full. You’re a kind person remember - you can show it by giving.
A handy productivity tip, a funny link in the #random channel (everyone could do with smiling more), a kool sticker for their laptop, a new mouse pad (hahahahah! got ya! no one uses mouse pads anymore!), or just a high five at the end of the successful deployment. booya! Yes, it’s ok to touch other humans in the office if it’s appropriate. High-fives are definitely appropriate when you’ve cracked that bug, deployed into PROD or received that awesome feedback from the customer.

Most of these are easy and things you can learn. They can be taught - if you’re unsure, ask a peer for help (#bevulnerable), and they’ll probably respect you more for it. Furthermore, I’m not a master of these either. They’re a daily challenge, but one I’m willing to work at. I hope you can think of it that way too.

That’s all I have for today. I’m going to head off to a team lunch soon and try to put more of these into practice.

Good luck!

–

Special thanks to Azella, Matt N and Ronnie for reading drafts.