DEV Community: Rus Kuzmin

Meetings – The Real Boss Fight

Rus Kuzmin — Sat, 14 Jun 2025 15:25:49 +0000

If programming is about solving problems, then meetings are about talking about solving problems. Or, if we’re being honest, sometimes just talking full stop (some people love the sound of their own voices).

Don’t get me wrong... some meetings are genuinely useful. Sprint planning, architecture chats, roadmap sessions that actually go somewhere. But let’s face it: not all meetings are cut from the same cloth. Some are just glorified calendar clutter.

"This could've been an email"

If I had a pound for every time I’ve heard that (or thought it silently while slowly dying inside) I’d probably have enough to retire. Or at the very least, a fancy coffee with some oat milk nonsense (Sorry! I just prefer lots of black coffee but that's just me).

You log onto a 15 minute Teams call with ten other people. No one’s quite sure why they’re there. Someone shares the wrong screen, someone else forgets they’re on mute, and that one poor soul keeps dropping in and out like it’s a wifi themed game of hide and seek.

You leave more confused than when you joined. Meanwhile, the jira ticket you were actually supposed to be working on? Still staring back at you, judging.

The stand up that never quite stands up

Daily stand ups are meant to be quick and snappy – “What did you do yesterday, what are you doing today, anything blocking you?” Sorted.

Instead, you often get:

A developer giving a full play by play of their entire Git history.
A line manager asking questions of which they should know the answers to.
A ten minute debate on whether the ticket title should say "fix" or "refactor".
Don't even get me started on PO questions...

And suddenly, a 15 minute check in turns into a 1 hour energy drain. It’s still morning, but you’re already emotionally clocked off.

Meetings named like boss fights

Alright, I’m not completely anti meeting. Some are genuinely great.

The good ones:

Help you untangle gnarly bugs with fresh eyes.
Leave you feeling more clear headed than confused.
Give you insight into what you've missed.

A 15 minute focused chat can easily save two hours of typing “any updates on this?”.

Deep dive architecture meetings? Lovely, as long as there’s some structure and not just yap, yap, yap.

But isn’t communication important?

Of course it is. In fact, I’d argue communication is half the job. Writing clean, clever code is lovely. But making sure others understand it is a whole other skill set (read my other posts hehe).

Still, if we’re in five meetings a day, wedging in bits of coding between them like some sort of productivity Tetris, something’s clearly gone wrong.

Am I wrong?

Meh, this is all just my experience, not sure if you'd feel the same but some questions for you;

What’s the most pointless meeting you’ve ever sat through?
How do you keep team collaboration alive without drowning in calls?
Should devs have the legal right to auto decline Friday afternoon meetings? (I’ll draft the petition lol)

I'm tired, and have been working over the weekend,

Still no gin,
Rus

So You Want to Be a Senior Engineer...

Rus Kuzmin — Thu, 12 Jun 2025 18:33:21 +0000

Ah yes, the elusive title: Senior Software Engineer. Sounds fancy, doesn’t it? Makes your CV look impressive, probably gets you a bit more attention on LinkedIn, and maybe even lets you escape the odd stand up meeting unscathed. But let’s get one thing straight... being “senior” isn’t just about how many years you’ve been bashing keys or the number of PR's you approve.

No, it’s a whole different game.

The 10x Nonsense

You’ve heard the legend the “10x engineer” who does the work of ten mere mortals, drinks black coffee by the litre (me haha), and churns out production ready code faster than the rest of us can open our laptops. Sounds cool, right? Shame it’s mostly nonsense.

Being senior isn’t about typing faster or writing smarter one liners. It’s about thinking first. It’s about building things that make sense, not just things that work. Sometimes, it’s about knowing when not to build anything at all and when to push back.

Yes, really... Sometimes the most senior move is saying, “Let’s not do this.” And then defending that decision in a room full of people who very much want to do it differently... like your PO or architect.

Welcome to Your New Side Job: Therapist

Once you hit the senior label, you’re no longer just a dev, you’re unofficially promoted to part time team therapist.

Junior dev’s stuck on a problem and quietly spiralling? PO stressed because a deadline’s slipping? QA pinging you with a blocker five minutes before Friday drinks?

Yep. That’s your problem now.

Your job includes keeping the team afloat, not just technically, but emotionally. It’s about guiding without patronising. It’s code reviews with tact, not condescension. Being gentle but not too gentle. Basically, don’t be that person... you know the one.

Some Days You Architect, Some Days You Mop

People think senior engineers draw diagrams, pick frameworks, and make smart sounding decisions.

Which is true… on some days.

On other days? You’re untangling ancient code that breaks if you so much as sneeze near it. You’re fixing “temporary” solutions that somehow made it to production three years ago. You’re muttering things like:

“Who approved this?”
“Why is this still running?”
“This makes absolutely no sense...”

It’s not all clean design and scalable microservices. Sometimes, it’s just holding things together with duct tape and prayers... until you figure out how to make it better, readable... understandable... manageable....

You're Now The Shit Barer

Now here’s the bit they really don’t tell you about: you’re the team’s umbrella.

You see, higher ups love a roadmap. They love a KPI. A slide deck. A good ol’ fashioned “Can we ship this in a sprint?” conversation.

Your job, as senior, is often to absorb the chaos raining down from above so your team doesn’t get drenched. You smile and nod in the meeting. You push back, gently. You translate nonsense into something your team can actually act on... or, in some heroic moments, make the nonsense disappear altogether.

You’re the reason your junior doesn’t have to hear, “We need this by Friday or the whole quarter’s ruined.”
You’re the reason the team isn’t stress chugging Red Bull at 9pm.

You take the hit. You shield the mood. You filter the madness.

And no, there’s no badge for this. Just another Slack DM at 6pm.

Senior DON'T Know Everything

Let’s clear this up: senior engineers get it wrong. All the time.

The difference is, when we mess up, we (hopefully) admit it, fix it, and help everyone learn something along the way. You’re not expected to be perfect — just honest, thoughtful, and reliable when it matters.

No one wants to work with the “senior” dev who never listens, never explains, and never helps. Do better, be better...

Final Thoughts (Before Another Calendar Invite Drops In)

If you’re aiming for the senior title for the pay rise or the shiny job title... fair enough. Just know what you’re walking into.

Less code. More people. Less control. More responsibility.
More impact. More teaching. More chances to shape something real.

With that said... still want to be a senior engineer?

Let me know... Or don’t. I’ll be in back to back meetings all day anyway.

Still no gin... but some wine,

Rus

Java Bytecode Is Just Magic, Right?

Rus Kuzmin — Tue, 27 May 2025 11:50:27 +0000

Let’s talk about something that makes beginners either squint at the screen in confusion or pretend it doesn’t exist (usually the latter) — Java bytecode.

We’ve all heard it.. “Java runs everywhere!” and “The JVM handles it for you!” That’s cute. But what does it actually mean? What is this "bytecode" thing that keeps popping up like some mystical middleman between your beautifully compiled HelloWorld.java and the machine actually doing anything?

Let’s break it down.

Write Once, Cry Everywhere

So, you wrote your Java programme. You clicked "Run" or mashed together some javac commands, and it compiled just fine (after the fourth typo ha!). But what did the compiler actually do?

It didn’t translate your code into something your operating system understands directly. Instead, it produced Java bytecode, which is like a weird hybrid language that’s not quite machine code, and not quite human-friendly either (not human friendly at all imho).

Bytecode is like Java’s own private dialect. Only the JVM speaks it. And the JVM? It's everywhere — from your posh laptop to some fridge in a smart kitchen that probably shouldn’t be running Java, but is...

Meet the Middleman: The JVM

Bytecode is universal. Machine code is not. That’s why Java gets to brag about being cross-platform.

Here’s how it works:

You write some code.
You compile it into .class files.
You give it to the JVM.
The JVM interprets or just-in-time compiles the bytecode into native machine instructions.

So yes, Java doesn’t "run" on your machine. Java bytecode runs inside the JVM, and the JVM runs on your machine. It’s like your code is staying at a hotel and the JVM is room service.

But Why Bytecode Though?

Because you get flexibility, portability and security.

Bytecode isn’t random gibberish. It’s a set of instructions that follow the JVM specification. Think of it like LEGO.

Well-defined blocks that can be assembled on any compatible baseplate (aka.. any JVM), regardless of what hardware you’re using.

Also, bytecode opens the door to:

Code optimisation by the JVM (which can make your Java app faster after it’s already running).
Language interoperability (Kotlin, Scala, Groovy, etc.).
Handy tools like javap, which lets you peek under the hood (and regret everything).

You Can Read It… If You Dare

Feeling brave? Try this:

javac HelloWorld.java
javap -c HelloWorld

You’ll see a stack-based language that looks like a combination of Morse code and mild panic. Stuff like aload_0, invokevirtual, and return.

Java isn’t just about classes, objects, and never ending getter/setter debates (sorry)... It’s also about stacks, constant pools, and instructions that feel suspiciously like "You're a wizard Harry".

Bytecode ≠ Bad

Don’t be scared of it. Bytecode is just the grown up version of your Java source code. It’s put on a suit, checked into the JVM, and started doing real work. And you don’t have to read it. But if you do, you’ll start to appreciate what’s really happening behind the scenes...

As behind all that high-level “write once, run anywhere” magic is a remarkably well thought out system that trades readability for serious power.. which works.

With all that said a few points I'd love to discuss:

Have you ever looked at bytecode? Did you survive?
What’s your take? Should beginners learn it early, or save it for when they’ve suffered enough, or should you even learn it?
Ever tried writing bytecode directly? (Please say no...)

Still no gin,

Rus

Memory Optimization in Java – Or, How to Stop Leaking Your Sanity

Rus Kuzmin — Tue, 20 May 2025 19:04:34 +0000

Let's start with the obvious, Java is great. It’s got a garbage collector, it keeps your hands mostly clean of manual memory management, and it’ll let you write code that just works. Until it doesn’t... Until that sweet little app of yours starts slowing down like it’s stuck in mud and your grafana memory usage chart looks like it’s climbing Everest with no plans to come back.

So yes... Java handles memory for you. But if you don’t understand what it’s doing behind the scenes, it’s only a matter of time before your app becomes jabba the hutt.

Let’s talk about how not to let that happen.

The Garbage Collector Is Not Your Maid

Java's garbage collector is fantastic. It takes care of unused objects so you don’t have to manually free() them like in C. But here’s the catch - the garbage collector only collects what it knows is garbage (shocker). If you're still holding references to unused objects even accidentally... It won’t touch them.

This is how memory leaks happen in Java.

Example?

Caching too aggressively.
Static fields that accumulate data over time.
Listeners that never get removed.
Sessions that never end.

Garbage Collection isn't magic. It's bookkeeping. If your bookkeeping is bad, your memory goes missing (I wish I came up with that).

Be Wary of Collections

The humble Listor Mapis often the first suspect when memory issues arise. Why you ask? Because we love shoving things in them and then forgetting about them.

Growing but not shrinking... Collections grow automatically, but they don’t shrink unless you ask them to.

Unbounded queues or caches? If you’re putting things in and never evicting them, guess what? That’s not a cache. That’s hoarding.

Tip: Use WeakHashMap when possible for caches - or find some good libs online.

In a weak hashmap, items can be cleared by the garbage collector if nothing else is using the key

Object Creation Matters More Than You Think

Creating a lot of short lived objects isn’t always bad... modern JVMs are optimized for this. But if you’re doing it in tight loops or in performance critical paths, it can hurt.

Examples:

Boxing primitives Integer &| Double in hot paths? That adds up.
Creating new Stringobjects from substrings for no reason?... We all know that person.
Logging full stack traces every 5 milliseconds? Please stop.

Know Your String Pitfalls

Ye Ol' String... Everyone’s favourite (probably the first data type you learnt when writing a HelloWorld app) but it’s also a memory hog if you’re not careful.

Every String in Java is immutable. So str += "To Infinity And Beyond!" inside a loop? That’s creating a whole new String each time (also your memory usage really will go to infinity and beyond... sorry ha!).

Some history for you (Something I learnt recently), old school Java used to store strings in the PermGen. Sure that's gone in newer versions BUT poorly managed strings still cause bloat.

Prior to Java 7, String literal in pool may be collected only if perm gen is included in collection (not every Full/Old GC includes perm gen in scope).

This one's for free: Use StringBuilder or StringBuffer when building strings in loops.

Tuning the JVM Isn’t Cheating

The JVM is powerful, but it doesn’t know your app. That’s your job.

Set appropriate -Xms and -Xmx Heap size values.
Choose the right garbage collector for your use case (G1, ZGC, etc).
- Introduction to Garbage Collection Tuning
Monitor using tools like VisualVM, jConsole, or others to get visibility into what’s happening under the hood.
Use the -XX:+HeapDumpOnOutOfMemoryError flag. When things go bad and you want to know why.

You Can’t Optimize What You Don’t Understand

You don’t need to be a JVM engineer to write memory efficient code... But you do need to know how memory works. Blind trust in the garbage collector will only get you so far - maybe pretty far (depending on what you're building) but when your memory usage is going to the moon? Goodluck, I hope you have lots of coffee and a nice boss.

So take the time:

Look at your object lifecycles.
Watch your collections.
Avoid unnecessary allocations.

You'll eventually start doing these things subconsciously..

And yes... every now and then... read a heap dump. It builds character.

A few things I’d love to discuss:

What memory profiling tool do you swear by?
Ever had a memory leak in Java that gave you nightmares?
Are modern GC algorithms good enough to let us “stop caring”?

Still no gin,

Rus

AI Is Writing the Code – But Are Juniors Still Learning?

Rus Kuzmin — Tue, 13 May 2025 22:21:05 +0000

Hello! It's been a while, a long while at that. I've been having conversations with a few colleagues and one of them stuck.

Something we've seen more and more of is junior engineers leaning heavily on AI tools to write code for them. Yes, AI is amazing (if used correctly). Yes, it can save time. But no, it’s not a magic wand that will turn you into a great developer overnight.

I’m not here to bash anyone. I’m here because I think this new mindset is holding juniors back.

Crutch, Not A Tool

“Why write it myself when ChatGPT can do it for me?”

I’ve heard this. I’ve seen this... But here's the problem: relying on AI without truly understanding what it's doing means you’re just copy pasting your way into confusion and most probably chaos. You get the code, it runs, you move on... but do you know why it works? Do you know what to do when it doesn't?

AI should support your learning, push you to understand concepts... Make it easier to grasp them with a so called "personal tutor", but not replace it.

Learning VS Skipping

Let me paint a picture: You’re new. You get a task. You feed it into AI. It spits out a nice looking function. You copy it, it compiles, you push. Cool, right?

Now fast forward a few weeks. A bug shows up in that same code. You’re staring at a screen, reading your own commit message, and realising you don’t even remember writing that logic. Because technically... you didn’t.

This is where things start to fall apart. Because programming isn’t just about writing code... It’s about understanding systems, debugging, improving, iterating. If you skip that learning curve, you’re skipping the core of the craft.

AI Is Not The Problem

Let me be clear... AI is a fantastic tool. I use it... You probably use it... And we should... to an extent.

But there’s a difference between:

“I wrote this logic, now let me ask AI how to clean it up a little,”

and

“I don’t know how to do this, let me ask AI to do all of it..." - while flooding private code to it HA!

Senior Engineers: Babysitting The AI

I’ve noticed a shift... PRs from junior devs used to be messy but honest!! You could see the thought process, the effort. Now? You get a pristine looking block of code that smells a little too clean. It’s syntactically correct, logically plausible, but you can’t shake the feeling: "Did they actually write this? Do they really know what's going on here?"

So you spend more time reading it. Line by line. Wondering if some obscure AI generated bug is waiting in there like a landmine.

And that time adds up.

Instead of fixing, working, you’re PR'ing some blind written machine code for errors (or security vulnerabilities) - Instead of working on more specific tasks.

You’re double-checking that they didn’t blindly paste in a solution that breaks something downstream. The safety net gets tighter, heavier, and more exhausting.

This isn’t sustainable.

Code review shouldn’t feel like reverse engineering ChatGPT.

That's all from me - just wanted to get my thoughts out there. Still no gin, though I've had a bottle of wine.

Rus

How To Be A Good Developer?

Rus Kuzmin — Mon, 22 Jul 2024 13:06:49 +0000

Hello! It's cough been a while... 4 years to be exact.

I've met a lot of incredible people over the last four years and have learnt from them all, everyone I spoke to and worked with brought a unique twist to what a "good developer" is so thought it'd be interesting to discuss this.

What Is A Good Developer To You?

Firstly, let's kick off with what it actually means to be a good developer. Everyone has their own perception of what this means and is typically influenced by the people you meet and the work that you do. Is a good developer someone who knows the ins and outs of the system that you're working on? Someone who is always happy to support and help? Or possibly someone you've never even met before? - Perhaps someone you watch on YouTube or read articles from? (hint hint).

I can't say what it means for you, but I can say what it means to me and for a tldr; I think... all of the above.

A good developer is someone who knows the ins and outs which enables them to help and support, they're responsible and are capable. They may master one disciple or multiple, they could also be a master of non. Is that a bad thing? I think not.

People are too quick to jump on the band wagon of "you need to master x,y,z".. but that takes time, and considering everything is evolving and changing constantly - can you really master anything? Or can you get very good for a short amount of time?

What Is A Bad Developer?

Now this is a tricky question, because I appreciate that everyone is good at something, and personally I think this comes down to personality and thought process.

Why do I think so? I'll give you a scenario - I worked with person x in company z, this person was a good programmer but a terrible developer. They would cut corners, not follow process and seemingly argue to attempt to prove a point (even when the point did not stand).

All of this took a toll on the health of the team, people became frustrated and the negativity that this person brang started to trickle into members of the team who started saying "I don't want to join the meeting if person x was invited".

Now, don't get me wrong. I am a firm believer of discussions - as this leads to better outcomes and results. What I do not believe in is trying to be the smartest in the room, like I said earlier, you're good at something but others are better in other things. If you have a point, put it forward for discussion and listen, afterwards reflect, is the way that you proposed truly better? if so, prove why.

This was a quick and short article, but I wanted to open up the floor for discussion. What do you think?

No gin this time, it's 2pm... I guess it 6pm somewhere! Ha!

Rus.

Programming is easy!

Rus Kuzmin — Sun, 28 Jun 2020 15:36:28 +0000

Gottcha! But seriously, there is still this misconception that programming is easy and that anyone can do it. Although, I do believe that anyone can become a programmer it certainly is not easy.

Get rich quick

"You're a programmer? Oh boy, you must be rich!"

I hear this far too often, though it is true that programming jobs pay well, this is not always the case and most of the time not for those that are starting their journey or in junior positions. This does, of course, depend on where and as a what you work as but the majority of the time it is, unfortunately, the latter.

I was interviewing graduates for a grad placement in the company I work for. 4/10 of the graduates asked me what my salary is, albeit it is because I am around the same age as them and I don't see anything wrong with this as it can be an incentive to sign up with us but, its the idea behind it that was evident from their follow up questions.

You can get rich from programming, but probably wont. If this is your only incentive to start or continue, I suggest you look at other career choices.

You need a certain mindset

I would argue that this is very much the case, you do need a certain mindset for this. There are several nights and days that I have spent staring at my monitor thinking 'It looks fine.. why are you not working!!?' Only to find a typo, improperly called variable or an unset property. This is frustrating beyond belief and can and will most certainly make you doubt yourself and your skills but you must keep pushing through and not give up. I am guilty of such crimes and have given up on many of my earlier projects because I've just become frustrated and did not enjoy what I was doing anymore.

Programming is problem-solving. Before you even type a single line of code you are solving a problem, your idea or your work has stemmed from an identified problem regardless of what it is.

Times have changed

Many languages are becoming more and more beginner-friendly and this is a good thing! but is it a great thing? The problem with simplifying things is that you lose the ability to do certain things. Take C++ and C#. In my opinion extremely different; C# supports garbage collection and automatically handles memory allocation (to mention a few) while C++ does not do either meaning you need to code the 'low-level' stuff.

It is getting easier and faster to do things, but by speeding down the highway you lose control over a few things... Sometimes important things. Take this as you will.

A few points I'd love to discuss in the comments;

Is knowing one language enough?
What would your response be to the title?

Still no gin,

Rus

Do Qualifications Really Matter?

Rus Kuzmin — Tue, 23 Jun 2020 23:14:48 +0000

Do I think you should strive for qualifications? Yes...
Are they necessary? Not anymore.

There was a time when it was almost impossible to acquire a tech job without qualifications but oh how times have changed.

August 2015

I was young and wanting to get into tech, I applied to a job listing 'exaggerating' my experience (I did work experience at a company and instead of putting down 1 month, I put 3... (Should've put 6). It was a small startup and I had the interview with the CEO. As soon as I was called into his office I knew that there was some hostility towards me. Before I said anything, and I quote - "What makes you think you could get this job?". My heart sunk and I went into panic mode and started speaking gibberish (I've never been made to feel like that). It went on with him making constant remarks about me being young and not having any qualifications and that he didn't know why I was even selected to come in, etc. I'm still in panic mode and have become upset (not visibly but inside I was burning). I managed to stay put and finally got put onto an aptitude test (which are stupid btw) and a coding assignment. I spent 20-30 minutes on the aptitude test and about the same on the coding task. I finished and went down into the lobby while he and his senior engineer reviewed. I was called into his office and he was different, very different. He was happy, saying how I did a great job and that he didn't anticipate this from me, bla bla bla. I was offered the job. I refused. Why? Because I'm not working for someone like that. I'd rather go back to being a lifeguard (which I did).

Don't be that guy... And if you meet someone like that, thank them for their time then politely see yourself out.

GitHub

As an ex-recruiter, this was my #1 place to explore when headhunting. You can literally see everything which is why I always emphasize the importance of GitHub to those that have no qualifications. You are showing your skills, your thought processes when writing; your commit messages are a gateway into your mind (don't look at mine they're gibberish). Believe it or not but you can really tell a lot about someone from their GitHub account - How active they are, their level of experience, do they cut/paste from StackOverflow, or do they actually take the time to deconstruct and re-build? Do they commit buggy code? This doesn't remove the need to actually meet with the person and offer them a task to complete but many headhunters shortlist based on this.

The New World

We live in an age where technological advancement has had a massive boom, Computers are cheaper, faster, and more efficient/accessible. There is nothing stopping you from learning and picking up new things. I don't believe that a piece of paper should dictate how good you are at something. There were many a time when I picked the candidate that had no, or very little qualifications because experience and knowledge are king .

Portfolio

I believe that everyone in tech should have a portfolio, and if you do have one you should be constantly adding to it. Your portfolio could be your GitHub account (see what I did there) or it could be a simple - this is what I've made and have it showcased somewhere, I suspect this is a little easier when doing things with a frontend and more difficult for backend developers but I'm sure you can think of something.

The tech industry has changed and is changing every day, for the better I hope. I'd be very interested to hear about some of your experiences, good or bad.

It's my birthday but no gin... yet,

Rus

The Rules Of Work.

Rus Kuzmin — Mon, 22 Jun 2020 22:05:41 +0000

Before we begin, I'd like to say that all these points may not resonate with you, but I'm 100% sure that a few will.

The 'rules' (and I say this very lightly) will vary depending on where and as what you are working as, or looking to work as. These are things I've noticed moving between smaller (startup type) companies and larger organizations.

Let's kick this off, we have a lot to cover.

You are going to make things that you don't like/ don't want to.

This is probably the point that will resonate with most unless you're working on your own project. You are writing code for someone else. You are in charge of creating their vision, whatever it may be. There will be times when you will disagree, offer alternatives, and sometimes get bluntly shutdown, this is normal. It's part of the job. IF this is the case and you can't work like that, I suggest you go freelance where you can decide and pick up the work that you like, but even then the client is in control, they will extend a list of functionality that they want to be implemented and it is your responsibility to implement. Bluntly, you'll have to take some s**t and bite the bullet.

You will/should disagree with seniors - sometimes

First and foremost, this is fine. There is nothing wrong with disagreeing with anyone in your workplace but there are ways to do this correctly which is what I see being missed by too many people. When disagreeing with someone is it just because you don't like the idea? or is it because it doesn't make sense? You know or have a better way of doing the proposed something? If this is the case layout your argument in this order.

"I know of a better solution which is XYZ"
"This will allow us to save money/ have better, reuseable code, improve security, etc."
"Can we combine ideas/solutions?"
"I suggest we at least explore the alternative, plan both out and come back to discuss and pick the solution that works better"

I see too many junior developers that have a wealth of knowledge hold their tongue because of a heirachy. If you cannot speak freely without the fear of being mocked, or ridiculed I suggest you move and move fast because you will be miserable.. Trust me on this.

There are always delays

Delays... A sore subject for Project Managers, and/or Product owners but they are conversations that are needed to be had. Delays happen, more so than not. And this is OK as long as you have justified reasons, Is it because you and your team were learning new things? Experimenting with new tech? As the agile saying goes, "We ran into Unknown Unknowns". Deadlines are there as a "We may have this finished by this timeframe but probably not" and they can and most probably will move. If you're working or looking to work in a large organization delays are inevitable, most of the time this is of no fault to you or your team but rather waiting for other 3rd party teams to implement something.

You will spend A LOT of time planning and designing

This one is a given. You will spend a ton of time planning and designing the code/ services you will write. This is a good thing, a plan of action, a map that you will follow. I recommend you do refinement as a team and ensure that everyone, regardless of job roles/titles understands what the piece of work is, this is especially important for junior developers. I used to get lost in my code or implementing things that are not needed because I would go off the rails and just jot down a few bullet points that I kept revising. Now, I know that designing/documenting is not fun, I hate it haha, but it is very important and should not be neglected.

These are a few things that I thought new/junior developers should be aware of. There are a number of further points which I may address later, but these to me are some that stood out and should expect regardless of where/who/what you work for/as.

No gin this time,

Rus

The Downside To Being Self-Taught.

Rus Kuzmin — Sun, 21 Jun 2020 23:53:28 +0000

First and foremost, I would like to state that I would recommend teaching yourself to code but, there are a few times when this could backfire which is something I think is important to discuss.

The Beginning

I started teaching myself from a young age, 15 if my memory serves me right (I'm 23 now), it was difficult, tedious but extremely fun and satisfying, this was way before they offered computer science as a subject in UK high schools meaning that I never had anyone to really turn to for questions or best practices which is really where some of the issues stemmed from - I became reliant on google.

The first piece of code I wrote was not a "hello world" but a Minecraft mod (I still think its pretty cool though). I remember seeing Markus Pearson develop Minecraft and thought that it was the coolest thing I've ever seen, making numbers and letters do stuff on the computer, it was amazing! How is he able to do this? (I was young...).

"Get it working"

When I started it I focused too much on the 'get it all working' instead of planning, designing, understanding the issue, debugging (properly), and ensuring my code was clean. I've spoken to a number of my friends and colleagues that are self-taught and they agreed on this point so I suspect these branch further out than my inner and outer circle. I jumped headfirst into getting code down (and this is something that I still do till this day - occasionally). This seems to be something young or new developers do, they get excited that their code is working and forget about everything else.

"Testing?"

Testing... Come on, I know you never wrote any tests when you were starting out, I sure didn't... I underestimated the importance of tests and testing the functionality of my code, It works... Why have tests? This could be the case if your code is not going to change, but what if it is? Say you're working in a large organization and your code goes through many mutations, you need to ensure that it does what it's supposed to do. I work in the financial sector, I cannot allow for the code I write to make a single mistake because that could be catastrophic. Don't get me wrong, I'm not perfect and I don't opt for a TDD approach each time (I should... but I don't). I think in general we underestimate the importance of tests and this is definitely something self-taught/new developers neglect or place on the backburner.

"You can't teach an old horse new tricks"

A saying - "you can't teach an old horse new tricks". I agree to a point. There are instances when I start writing code rather than sitting back, understanding what it is I'm trying to do, planning out my code, and then start to write. This is something that I learned to do from working in a large organization and from senior developers, a good friend and colleague of mine said this to me when I first started at the company - "Programming is 90% figuring out what to write, and 10% actually writing it".
At the time, I didn't really understand what he meant as back then I was working on "simple" stuff, but oh boy... Once we moved onto bigger and more complex projects, my lack of experience started really showing, and you may attest this to me being inexperienced but these are things that you SHOULD learn at university, and/or some very good programming courses.

It's been a long night and just wanted to get some of my thoughts across, there are a few more points which I may add at a later date or make a part 2 of this post, but the gin has caught up to me.

Goodnight,

Rus.

Java/Spring Twitter Bot

Rus Kuzmin — Fri, 19 Jun 2020 17:35:45 +0000

Ah, ye ol' twitter bot... Gotta love them.

I've been sat at home for the past couple of months self-isolating and have become dreadfully bored.. So why not work on a cool little project? I definitely didn't get super excited and giggled like I was witing my first hello world when the @ItsMelonBot actually posted a tweet.

Believe me, I know its nothing fancy, I essentially do this every day at work but it was still pretty cool non the less... It the little things in life!

The journey began with me going through medium until I came across a post 'cool programming projects' and saw the twitter bot and thought... why not.

I needed an idea, a retweet bot? Boring. A trend bot. Booooring. How about a melon bot?... A what?

I kicked started Intellij and started the process, had it finished in 15 minutes or so. The thing that did take me ages to get my head around was deploying it into Azure. Now that... that was a b****. I tried to sign up to AWS but for whatever reason AWS didn't like me very much so off to Azure I went. Azure is seriously complicated... It took a while to get my head around how it all works but we got there in the end and it made deploying my bot to the cloud much faster and easier.

For anyone interested, I've created a public GitHub repo with detailed documentation and comments on how to get it up and running, thought some of you would like to play around with it or add some functionality.

https://github.com/goldennoodles/Spring-Twitter-Bot

Just wanted to get my thoughts on paper. If you would like to see a full tutorial on deploying it, etc. Let me know!

Oh and follow the bot, he's pretty funny.
https://twitter.com/ItsMelonBot

Rus - ItsMelonBot's papa.