DEV Community: Nick Cinger

Surviving the Legacy

Nick Cinger — Mon, 28 Oct 2019 08:20:46 +0000

Legacy code. Just reading the words out loud will make developers wince. Partially 'cause of their own horrid experiences, but also because of an ongoing meme that Legacy code is literally the worst.

This meme has origins in reality. Hard to debug and dificult to rewrite code is nobody's dream. The dream^tm is building a brand new, fresh out of the oven, no-prior-baggage project in which the code editor is your oyster.

The dream is definitely not "going down a decade old rabbit-hole of debugging". The dream might be "working on a new feature without having to think about how it's going to break another part of the system".

Alas, you don't always get to pick. You work with the cards you're dealt, and folding your hand is a tempting option. I'm going to make the case for staying in the game even if it feels hopeless at times.

But first, let's paint a picture of a Legacy code-base.

The background

Just in case you're not currently working with a monstrosity, let's give you a background of an "imaginary" project. The project is 10 years of tech debt. It had started as a mish-mash of code from several developers, working with no clear guide or vision.

The higher ups, thinking that 5 average developers are better than 2 great ones, had thought that they were a better cost-to-code ratio. None of the developers had the necessary experience to see where the project was going. They were busy working away on their own little corner of it, not paying attention to the bigger picture.

So you have several contributors to the code and no style guide. You also have no oversight, no code reviews and obviously no unit tests nor documentation. But hey, they were churning away, knocking down requirements one by one.

Since there wasn't a proper release or testing process involved, there were bugs. God there were bugs. And then the merge conflicts came. And so the developers started dropping off, replaced by other new ones, adding more to the confusion.

A few years into the project money was growing tight as the product was sub-par in an overcrowded market. Features were coming out too slow and they were too buggy to keep users interested. As a result, deadlines became tighter and code kept getting worse.

But somehow, through it all, the project turned a profit a few years in. It had users and money coming in. So now stability of the project is a lot more important than it was while it was still just under development.

There is still no documentation. The best you could hope for are random code comments and the outdated knowledge base. Unit tests have been poorly implemented. They run too slow and developers have to run them manually. The result: nobody runs the tests.

A few more years, the project is actually making bank. The code is officially "Legacy" and is a proper pain to work with. But the business can't sit still, it needs features and it needs more developers. Gradually the consequence of the aged code-base become evident.

The consequences

You're Johnny Newdev. You've been hired to supplement the developer team and help them fix bugs and add features. The hope is that you'll be doing more of the latter, but as time goes by you see it's more of the former...

It took the team lead a week to onboard you. The team is already swamped and now they have to spend time setting you up. Unfortunately they haven't done this in a while and the process is not documented. You're given this Disk Image of what seems to be everything and the kitchen sync of the project, but even that doesn't work. You have the code, a virtual machine and a hastily prepared development database.

The first few days are spent debugging network and database issues. The rest are you adding the undocumented dependencies to your system. On day 5 you can finally load the website locally without any (major) errors.

Parts of the system still don't work, but you're told not to worry about it. "We'll set you up once you need to work on those bits" is what you're told. Of course those are the bits that actually need to be worked on, so you spend a few more days setting those up.

Finally you're fixing your first bug. The lead developer is confident that there's no way you can muck it up, seeing as it's an isolated part of the system.

Your code is online. Half an hour later the team finds out the signup form is broken. Whatever you did, it worked locally, but the code behaved differently on the server. You go into firefighting mode and fix it on the server to not waste time with the slow deployment. Yes, for some reason you have root access to the server.

So now that it's fixed, you're terrified of changing anything else. You triple check your code and keep a very close eye on Production once the code is online. This also means you're behind on your deadlines which in turn means you're rushing stuff out, which means you're doing even more firefighting. It becomes an endless, but expected, cycle.

You think back to this game you played a while back, called Dwarf Fortress. In the game you manage an expedition of dwarfs, mining through the mountains to build out a fortress and accumulate fortune. The game has it's own definition of FUN. One of the most common ways to "have FUN" is the so-called "Tantrum spiral".

It starts with one of your dwarfs getting into a foul mood for whatever reason. Maybe they saw a dead animal, or a piece of art rubs them the wrong way. They now proceed to punch the dwarf nearest to them out of frustration. So now you have two pissed off dwarfs and they spread the mood further. Two become four, four become eight and eventually your entire fort grinds to a halt. Everyone is too exhausted or angry to work and the lack of beer is not helping matters. And then the goblins come - your adventure ends.

You're seeing the Tantrum Spiral play out before your eyes. Releases are slow and buggy, which means the users are unhappy. Money starts to dry up so management gets pissed. Developers are put under pressure to produce more and produce it faster. The result being that team produces buggier and less stable features, which in turn angers users, which angers management again, which fires a developer in attempts to "fix" the new budget problems. This just makes things worse and the spiral downwards continues.

Damn, just writing that out is giving me anxiety.

The problems are obvious by now and the team is brainstorming solutions.

The "not actually solutions"

Let's start from scratch!

Yeah, that would feel great! Just throw away the baggage and use the things you learned to build a better product. So, what does a timeline for this look like?

The project has years of features behind it. And although you could build it faster this time, it would still take you a year at least. That's a whole year of:

No new features
Less new users
Lost users
Lost opportunities

And there's no guarantee that the end result is going to be all that great or even on schedule! This is the development equivalent of nuking the planet because you're fed up with wars. The thing is, that's not a sure-fire way to get long-term world peace. Odds are that the newly formed nations will just have history repeat itself.

Eventually the same problems that got you into this mess are going to start creeping up again - unless you deal with them first. And that's assuming that the business survives a year of code-freeze, even if you could produce that pristine piece of perfection you're imagining.

Let's migrate to this new tech

No. Just no. Even entertaining this idea as a feasible suggestion is a sign of either a very inexperienced developer, or a developer that loves chasing the new hotness. Neither of those will help you claw your way out of Legacy - they're liable to just plop you into a soon-to-be Legacy code-base.

You should stick with battle-tested frameworks and processes for a few reasons. For starters, your team probably has more experience with it, and even if they don't the internet has years of solutions to problems with the given tech. Imagine going to Google and not finding a solution to your problem?

Even worse, imagine going to Google and the only result is a link to the same question you have. But it has no answer yet and it was posted only 8 hours ago.

Best case scenario, the new tech is supported long enough for you to finish your migration project. Worst case, it's abandoned for the next trendy piece of tech while you're mid-way through the rewrite. Good luck rewriting the rewrite.

Granted, if the tech you're using is already deprecated, you should at least entertain the idea of a proper upgrade.

In that case, let's work on cleaning up the current code without working on new features.

This idea is not going to make it past management, and for good reason. Again you're putting the business at risk, and with it your chances of making it to the end release. But this is the closest one to an actual solution, and with a few more pointers it can be part of your battle-plan.

I think we've painted a bleak enough picture. Let's talk solutions!

How does one fix "debt"? You start paying it off.

First of all, the Legacy code-base is not the cause of your problems. It's just the most glaring of all the side-effects. And if googling medical conditions online has taught me anything, it's that you should treat the cause and not the symptoms!

Start fixing what got you into this mess in the first place.

Standardize processes around development. It's more than just style guides and folder structures for your code. It means actually writing documentation. It means automating deployments. Automated tests have to be the cornerstone of your project, and not just an afterthought.

Obviously you're picking up where you left off with your code. You can't throw it all out (we went over this) but you can follow some guidelines that will clean things up in the long run.

Anything new that you write has to be good, unit-tested, documented code. You don't have time to go over the entire code-base, but as you touch parts of the bad code, you make a point of cleaning it up. Again, this means documenting it, adding test coverage and making sure it goes through a code review. There are several approaches to this, but those are topics of their own.

Allow for new features, because the business needs to keep running. But don't allow anything half-assed, under-researched or rushed out. You're already spending hours every week dealing with the fallout of the current code. You can't afford to add more tech-debt to your project.

So now you have an idea of what your schedule looks like. Part of it is working on new features. Part of it is doing cleanup of old code and part of it is "firefighting" due to the aforementioned code. A third of your development time each week should be spent on cleanup and optimization. This is going to hurt in the short run, but pay off in the long run.

Maintenance is you spending time on a launchpad today, so that you can propel your project forward tomorrow.

The goal is to pay down as much of the tech-debt now so that you can increase productivity down the road. This kind of maintenance is a constant thing. Make sure it's part of your development schedule moving forward.

You could throw more money at the problem by increasing the team size, but that's not going to be efficient. It depends on the business side: are you now producing features fast enough? If the answer is no(as if it's ever yes, when asking management), then you need to make sure you have a decent developer on-boarding process.

If budget does not allow for growing the team then the scope of the project should be dialed down. You need to make sure you have a good balance of productivity and code quality. You can't always have perfect code, but make sure that it's at least maintainable.

And, in case it's not obvious, the developers need to convince the rest of the company that whatever you decided on is the way to go. This means convincing them that you need to make this investment, and that it will pay off. The tech-debt metaphor is familiar and easily digestible - use it in your arguments.

The Pay-off

Obviously, the above is a lot to commit to. But the results are tangible. The project can be salvaged. Legacy becomes maintainable and keeps making money. Once there's more money you can get crazier with development. You can break the monolith down to micro-services. You can migrate everything to AWS. You can change your mind and string the micro-service back into a single code-base.

All that and more you can do after you've solved the underlying problems of your project, and kept the business running in the process.

You now have predictable releases. You have a stable product. You have well-tested, documented code that you can work on with more confidence. You do less firefighting, you anger less users, the business makes more money and the development team can keep growing efficiently. Happier developers, happier users, happier management = successful product.

The exact architecture and approach of your "survival" can take many forms. Share your horror stories and successes in the comments and let's show the developer world that there is a light at the end of the Legacy tunnel.

attribution: cover image is from the game Dwarf Fortress, messy cables, neat cables, brainstorming, _Comic from MonkeyUser.com

How to kill your motivation in 4 easy steps

Nick Cinger — Wed, 16 Jan 2019 08:49:31 +0000

Keeping your motivation in-check can be difficult, and while it seems like it's something that's totally out of our control, we can impact it in significant ways. Your motivation will swing up and down based on whatever your circumstances are, but let's talk about ways of keeping those pesky dopamine levels down.

Never say "No"

If you don't already have a soul-crushing task to work on, look no further than your immediate surroundings. People are brimming with ideas that they are 100% behind, as long as they don't have to do the work. And they're willing to give you lots of free exposure! I mean really, who could turn that sweet deal down?

What's more, these ideas are everywhere. To really get demotivated quick, take on 3 of these at once to make sure you have a steady supply of "when's this gonna be done?"'s, and "my nephew could have done it in one afternoon"'s. Nothing kills willpower more quickly than working on a project you don't care about, for people who don't care about you, while seeing 0 returns.

If you already have a paid gig, just remember to accept any project, idea or responsibility that the company throws your way. Saying "No" looks bad, you know? Even if it's something way out-of-left-field, I'm sure you can pick it up in a weekend. I mean, Marketing, Programming, SEO, Management, DevOps, Photoshop - these are interchangeable skillsets. And then, once your TODO list still says "MONDAY TASKS" and you're well into Thursday, you'll start to feel your motivation slip away.

Take on overambitious goals

A sure-fire way to get started on the path of moti-death, is to get yourself something unachievable to strive for. This might be more of a long-con thing as it will take you a while to get to the disappointment phase_ but trust me, you will get there.

There are a few important guidelines you need to follow for this to have it's full effect.

First of, avoid any planning or research before committing to a deadline. The only way to fail spectacularly is to not be aware of what you're getting yourself into. Just dive straight in! Or as we say in my native language: "Go throat-first into the strawberries". For bonus points, give an estimate 5 seconds after hearing the idea for the first time.

Even if it's something you could definitely see yourself doing, put yourself into a no-win situation by making and planning around unrealistic timelines. Even if you somehow manage to finish the task you'll finish it 200% over the promised deadline and this will take all the wind out of your sails.

And right on time to start that next project, which is already late due the lateness of the previous one! You're demotivated, and you haven't even started, kudos!

Allow all distractions

In the internet-era, this is the easiest thing ever. Be sure to allow all the notifications. Preferably with on-screen pop-ups and sound. Put the idea in your head that you need to see and respond to every message immediately. The phone must not go into "sleep" mode. Keep it within your view at all times. Every call might be urgent.

The point is to avoid being focussed. Focus leads to getting into the zone, and that leads to high levels of motivation - and we can't have that!

An easy way to accomplish this with zero effort is to work from home, or in an open-floor office, without setting any boundaries. Just let the natural flow of your surroundings generate the distractions for you. Remember to not put on your headphone either, can't have people thinking you're unapproachable.

Work over-time, get burned out

I mean obviously the only way you can even hope to meet those promises, right? Right!?

All the feel-good quotes tell you that if you just give it your all you're sure to succeed. BUZZZ WRONG. Giving it your all is just a fast-track to the double-motivation-dip, because now you've not only failed, but you failed spectacularly. You are left feeling exhausted with an overarching feeling of inadequacy.

Once you're properly burned out, your motivation will be in the negative numbers at this point. You won't be able to do any meaningful work for weeks probably, so you'll be safe from getting too motivated for some time to come! Just remember to always push yourself to the edge - and then right over that edge!

And remember kids: Treating yourself mean will scare away that Dopamine!

Fixing your Documentation Problem

Nick Cinger — Sat, 27 Oct 2018 16:03:07 +0000

You might feel like you don't really have a problem, but statistically speaking, you probably do. And even if you do have documentation, there are ways of making a better habit out of writing it.

We'll go over a few of the go-to excuses(not to be confused with "excuses for using goto") and discuss approaches to fixing this.

The Pains

If you've worked on any project that is not 100% your own making, you've had plenty of problems due to outdated or lacking documentation. I don't mean to invoke those painful memories(feel free to skip ahead), but let's go through some of the more serious ones, for those that haven't shared in the joy of coding blind.

You're plopped into a project for the first time, and if you're lucky you have colleagues that have been here longer than you that can help guide you. And if you're born under a lucky star, they will have the patience to help you and documentation to point you too.

But, alas, most are not so lucky. Most likely you're thrown into the deep end by yourself. Alternatively, you're not alone but your colleagues are too busy drowning in the same mess. Lack of documentation means you're stabbing in the dark, breaking things more often than not, and regularly misinterpreting how the system works.

Your days are filled with reading logs and stack traces, putting var_dump($data);exit();s everywhere while you attempt to make heads or tails of the thing. By the end of the week you're exhausted and your TODO list isn't any shorter. This might sounds like a Legacy^tm problem, but it happens with young projects as well.

To make matters worse, you quickly become part of the problem. There are no "documentation guidelines" on the project, and you don't have time to be the first one to get the ball rolling. Instead, you rely on your own notes, spread across your notepad and .txt files. More often than not you go into the source code, 5 levels deep in the stack, to figure out how to fix minor spelling issues.

The day you figure out how to use CTRL+SHIFT+F(find in files) is the day you decide that you don't even need documentation, because you know your way around. And this becomes one of the many crutches you'll need to get by on the project.

The Excuses

Programmers tend to think of themselves as highly rational people. And this may very well be the case, but they take it a step too far, by rationalizing their mistakes and laziness, thus making it very hard to change their habits.

The favorite excuse (of us all, I might add) is:

"I comment my code well enough, I don't need extra documentation."

While it might be true that your code is the pinnacle of descriptiveness, the fact is that if you have to dive into the code to understand a feature you're already making a mistake. It makes sense to dive into the source to make estimates or understand the nuances of the process, but if you're looking at source code to understand a feature, you have a documentation problem. Now, dialing this excuse up to 11:

"My code is descriptive enough, I don't need documentation on top of it."

This can only be true if you're writing the simplest of CRUD apps. And even with CRUD apps there's a case to be made for proper docs. Additionally, you're not the only person needing the documentation. As the company grows the documentation will become useful to:

Other developers
QA testers
Sales and Marketing
You, 6 months after writing the feature

The list goes on, and the sooner you start writing docs, the less issues you'll have down the road.

"Sorry, we don't have time to write documentation, we move fast and break things!"

This is the same excuse used for the lack of writing unit tests, and in both cases the result of the new habit will save you time down the road. Sure, in the short term it seems like a waste of time, but it pays dividends as you go.

Not to mention that writing documentation takes comparably no time at all. I know, it feels like forever when you're writing documentation, but you're actually done within 30 minutes or less, for any single feature.

The only somewhat reasonable excuse to not write documentation is that the project is so small that it doesn't really need documentation. But here's a simple rule of thumb for your project size:

If it's worth building, it's worth documenting.

The Solutions

In a company with a development team of any meaningful size(ie, >0) you will come to know the joys of having a process. Whether you're a tester, a manager or a developer, you'll already know that a project needs some guidelines in place for the more "boring" work, so that more thought can be put into the "fun" work.

Document first, ask questions later.

I have to admit, when I got this idea, I thought it was revolutionary: along the lines of "Test Driven Development"; and that I was being super-clever by naming it "Documentation Driven Development". And then I did a quick Google search and realized that it's not a crazy new idea, and that people have been doing it for years(or decades, if you include "waterfall" based projects).

Alas, I'm not as smart as my mom thinks(sorry mom!), but I think the idea bears repeating. Before you dive into the code, write up the documentation.. And before you start rolling your eyes: yes, you can't get every detail right before getting to the code. But you can get the "story" right. You can get the "business value" and "usage patterns" right. There's a lot to gain:

You get to jot down your thoughts, to flesh out the idea
You get to run the documentation by other people, to make sure you understood the problem correctly
You have a clear road-map of work involved, as well as a list of edge-cases and "nice-to-haves" for the future
And with all of this you're fixing your documentation problem

Think about it like this. Nobody feels like writing documentation after the fact. Once you've banged out that big feature, you feel like grabbing a coffee and taking a break. But, if you have documentation ahead of the code, then suddenly you're writing it while the initial idea is still fresh.

The whole idea has a lot of overlap with TDD, which it also has a great synergy with.

That said, don't forget to document the changes and bug-fixes. If you don't do that as well, you're setting yourself up for documentation rot. It's a lot like technical debt, in that it will come back to bite you in the ass in the future.

As a bonus, start documenting every bigger post-mortem, describing how you discovered and fixed big problems at the project. This is a big topic on it's own.

Even if you already have a big project and no documentation, now's the time to start. Like Gandhi said, the only better time for starting documentation than today, is yesterday, or something along those lines. You start by documenting new features, and continue by documenting anything you touch or change. Much like with writing automated tests, and increasing your test coverage.

And before you know it, you'll have a great reference point for all of your team-mates, and maybe even your users! Who knows, if you do this correctly, you'll stop cussing out your past self, for being too lazy to write it.

Keeping your scripts alive and healthy

Nick Cinger — Fri, 24 Aug 2018 15:12:33 +0000

There comes a time in every sysadmins life when he needs to let his scripts take on a life of their own. They start working on big jobs for hours on end, and it becomes unreasonable to keep staring at the terminal to make sure everything is ok.

But, like any good helicopter-parent will tell you, you can't trust your ~~kids~~ scripts to do the right thing! Your job is to bring them up correctly, point them in the right direction and ~~hope~~ make sure they make the right decisions. Here's a handy check-list to put the ~~mental~~ fun back in fundamental!

1. Be clear! Absolute paths everywhere.

One of the more common gotchas when writing scripts is assuming the startup directory of the script. You can't afford to be vague like that! Don't let them guess the context, hard-code it in.

For example, you're testing your script locally, and it's looking great! You are now prepared to say "It works on machine!" even after it breaks in production! But that won't save you once your script just does not start from the crontab, because of something simple, like a bad log path.

Ways to approach this:

Define the absolute paths within constants on top of the script
Include the paths from the environment
Or get the current directory path from within the script
Require the "start path" be provided when running the script as an argument

2. Keep tabs on them! Log everything.

So, while you're looking directly at the output as it's happening, it behaves wonderfully! Your ~~child~~ script is a well-behaved and productive member of its environment. Surely you can let them do things on their own?

WRONG

If you're not paranoid at this point, you're just unaware of all the things that can go wrong! From paths and permissions and all the way to broken loops and undefined behaviour, there's a myriad of things that can break - and you should have a paper trail of it happening.

The last thing you want is having to debug a major outage by having to cause another one!

If you're running your script as a cronjob, it's easy to log the output:

0 9 * * * bash /var/scripts/check_messages.sh >/var/scripts/logs/check_messages.log 2>&1

The above will run the script once a day, but will write to the same log file every day, overwriting it. So you can get yesterdays output. That's the least you can do. Also notice the absolute path for the log file as well! We're not messing around.

Alternatively you can have logging within the script itself. A few things to keep in mind:

Use timestamps everywhere! You need to know when something happened.
If you think it's needed, include email alerts, so you're notified about critical issues on time.
If you're keeping most of your logs, use logrotate. You don't want to run out of disk space because of your logs.

3. Don't assume that it won't fail! Supervise it.

Say your script is some kind of polling script, or something that needs to run forever. That's not something you should be starting and stopping from the crontab. It's also not ideal to get a notification just when it dies - it should restart on it's own as well.

Supervisord to the rescue!

This is an awesome tool you need to be using in these cases. It's like the best personal trainer out there! He never sleeps and just runs after your processes yelling "No slacking! Keep running!".

For example, I've recently had issues with the Docker deamon dying from time to time. Obviously, me jumping into the server to start it up again was unproductive, so I added this to the supervisord config file:

[program:dockerd]
command=dockerd
autostart=true
autorestart=true
redirect_stderr=true
stdout_logfile=/var/log/dockerd-supervisor.log

This tells it to supervise the dockerd process, and to restart it when it dies. It also logs what's happening to a log file we can use for debugging later on.

And this works with your own scripts as well! It's also neat if you have a script that only runs for 1 hour and needs to start back up again. This way you avoid having potential same-process overlap like when using cronjobs.

4. Have a way to stop them! Teach them the signals.

Eventually, you'll want to be able to tell the fruit of your ~~loins~~ keyboard to hold on a second while you reconsider what's been happening. If you don't plan for this ahead of time you might end up sending hard-kill signals like SIGKILL which can have nasty consequences.

Bad things that could happen by killing a script mid-way:

File permissions stay wrong
Corrupted files or database data
Orphan processes and half-processed data
Unreleased resources

To avoid the above, you should put in a SIGTERM handler. You can do this in most any scripting language, I even have it working in my PHP scripts.

This way the script can finish what it's doing, process it's current batch of data, finish writing that CSV file line, and release all the used resources. So, when you write killall -s SIGTERM dockerd you let it finish what it's doing before it stops.

Also, minor side-note: if you have sleep() code in your script, the sleeping will be skipped to speed things up after it receives the SIGTERM signal. Speaking of sleeping...

5. Make sure they're not selfish! Don't overload the system.

The great(and terrible) thing about your scripts running is that they will try to get the most out of the resources available. So if they're transferring a 1TB file over the network, you'll wish you'd changed the WiFi password!

They need to realize that they're not the only one in the ~~flat~~ server and that they need to clean up after themselves, as well as not hog the utilities.

There's a few guidelines you can go by to make sure they play nice:

When transferring over the network, use upper limits. For example rsync has the --bwlimit parameter for this.
When bombarding the database with queries, give it some leeway - sleep the script from time to time.
When writing heavily to the disk, make sure it's not hogging the disk that the database uses.
If possible, have it run during off-peak hours, and monitor the server performance.

Summary

So that's my list of "script" lessons I've learned the hard way - so you don't have to! Do share your tips in the comments as well, and point me (and others) to other nice resources on the subject.

You can never be too careful with them!

Mandatory disclamer: I do not condone helicopter parenting when it involves real children as opposed to child processes.

Konsole, SublimeText and PAC Manager for a devs workflow

Nick Cinger — Sat, 04 Aug 2018 19:30:44 +0000

To start, my Operating System of choice is Ubuntu. Right now I'm on 16.04 but plan to move to 18.04 by the end of the year. The only thing lacking are Adobe programs, but that's not a huge issue for me, as I mostly deal with backend work.

I've used Windows for years, and it was ok but not great for development. At one point I got myself a Macbook Air, and used that for a while, enjoying the terminal, especially iTerm, but really disliking how closed the entire Mac system felt. I ended up frying the thing accidentaly with coffee, and the fact that I couldn't just open it up myself really ticked me off, so I swore off Macs after that. I'm just too used to messing with my rigs: something that I had with Windows machines, and have again with my Lenovo Thinkpad. I've happily openned it and added an SSD and extra RAM to help it everything smoothly.

For the most part I really like Ubuntu, but there are some things that get to me. The one ongoing issue is driver trouble, as my WiFi randomly disconnects for a second, and god forbid I put the laptop in sleep mode. Waking it up leaves me without WiFi or sometimes a functioning audio jack.

That aside, I love what I can get done and set up on Ubuntu, and I'm still growing into it. Bonus points for it basically being a great way to practice my DevOps skills, which are part of my daily work.

Code Editor: Sublime Text 3

My first few years of dev work I used Notepad++. I liked it compared to the bigger tools at the time and felt that I'd learn code faster than if I was using something with autocomplete. That worked out great, but only because I was mostly doing PHP, and not something in dire need of an IDE, like Java or .NET. A few years into my career I switched from Windows to Mac. As Notepad++ wasn't available, I started looking around fo something similar. I found Sublime Text 2(at the time) and immediately fell lin love.

It had everything I loved about Notepad++ with extra bells and whistles. The most important things were speed and customizability. The only thing that beats Sublime in terms of speed is VIM, and I haven't found the time to learn it - although I'm looking to try at some point. Also I have massive respect for the creator of Sublime for making it free to use(nagware) and for the inovations he brought to the table, which others later copied.

The plugins I probably notice the most:

For syntax:

Todo.txt Syntax - I use that in my "todo" file
Markdown Extended and Markdown Preview - our documentation is in Markdown
VCS Gutter - basic Git and Mercurial indicators for new/removed/changed lines

For cleanup and readability:

FileDiffs - easily compare files or snippets for differences
SQL Beautifier - indents SQL
JSON Reindent - reindents JSON
HTML Tidy - reindents HTML (we work with a lot of HTML emails)

Code Styling:

PHP Beautifier - cleans up PHP (indentation, brackets, etc)
PHP Array Syntax converter - convert array() to [] syntax
DocBlockr - generates Doc Blocks

And a few more minor ones. I end up doing "plugin purges" from time to time, to keep Sublime snappy.

Terminal usage: Konsole, OhMyZsh and PAC Manager

Since leaving Macs, there is only one thing I miss: iTerm. I have yet to find a tool that's so powerful, yet so easy to set up. I've tried everything available on Linux and no one tool does it for me. What I loved about it:

great keyboard shortcuts for managing sessions
saved and predefined sessions you can re-use
new sessions are super easy to set up and use
You can start specific server connections, with specific commands, with keyboard shortcuts

Now, I know tools like terminator can probably do most of this, but I don't want to have to be a 1337 hacker to get my tools to do what I want them to do. I'm willing to spend some time on it, but if I can't figure it out in a few hours, I move on to the next one. I ended up finding a good balance with Konsole. It gives me a nice customizable starting session, with a few nice shortcuts. It's not good enough for managing servers so I use PAC manager which feels a bit clunky at times but is actually great if you want a lot of ready commands to send to servers. Both of these take longer to set up than iTerm, but together they do a great job.

With PAC manager it's easy for me to open a dozen SSH tabs, some for viewing logs, others for monitoring performance on the server, and some for running commands. The only problem with PAC (that I didn't notice until writing this post) is that it hasn't been updated in 2 years. I've been using it for the past 4 years or so, and I don't see a particular update need, it runs great on every Ubuntu version I've used so far.

Also, my Konsole looks like this on boot-up:

The matrix looking numbers are from the command cmatrix I use it as a screensaver. Once I start typing they go away. I use OhMyZsh for my shell, it just makes shell usage easier and overall nicer.

I use the default 4 workspaces in Ubuntu, and keep my windows organized in 4 groups:

Editor (Sublime)
Browser(s)
Terminal (Konsole)
Server terminal (PAC)

Miscellaneous apps get opened wherever makes the most sense at the time.

Once I have some time I'd love to set up i3wm and learn how to use it. I've seen some great setups over on Reddit. I tend to take a few hours per month to tweak one or two things about my setup. It's easy to get lost in it, so I limit myself, otherwise I'd be tweaking for days!

There's a whole slew of minor tweaks I did to make my system feel like my system, but this is the birds eye view. I urge you to share your setup with us as well, as one can always pick up some pointers from posts like those.

What kind of content do you want to see more of on Dev.to?

Nick Cinger — Wed, 25 Jul 2018 10:34:55 +0000

I've got a few ideas floating around I'll never get to, and some things I want to see, so I wanted to hear from you folks as well. Figured this could be a useful resource for new people here that don't have any topic ideas :)

I'll leave my suggestions in the comments, and you do the same.

As a bonus, the replies to comments should be links to articles scratching that particular itch, in case the original commenter didn't see the article before!

Slack keeps interrupting you, but you can stop it

Nick Cinger — Thu, 12 Jul 2018 13:18:32 +0000

Or "Avoiding death by a thousand cuts". With your productivity being the victim.

The cheapest way to kill a programmers productivity, is to get him on a company Slack team, include him on all the channels, and give everyone free reign to poke, ping and prod him at will. The onslaught of dings, popups and push notifications will tire him out pretty quickly.

Just as humanity hasn't yet evolved to deal with online social networks, so too programmers are still a few generations away from fully figuring out how to survive instant messaging. And not just programmers, this includes any profession that needs to stay focussed for hours at a time to get meaningful work done.

Slack might cost only $5 per user, but if you take into account the lost productivity I bet that figure becomes just a rounding error on your balance sheet. That is, if you're not using Slack correctly.

What Slack isn't

Ok, so here's the thing. We've been blaming Slack for concentration-genocide ever since it became the de facto chat tool. Companies love it, clients love it, but programmers only tolerate it. I'm going to argue that we've just been using it wrong.

Slack is not meant to be real-time

Think about the forums of old. You would leave a well thought out message, hoping to get an answer, and go about your day. You would either return a lot later, or once you've received the (pretty slow to arrive) email notification of a reply.

You would be greeted by a similarly well thought out message. Not 10 sentence fragments spread out across a line each, and certainly not someone’s incoherent train of thought, the point of which was lost mid way.

Somewhere along the way...

We decided

that this

is an acceptable way to communicate.

Please. Stop.

Not only does it vibrate my phone off the table, it breaks up a single message into a dozen interruptions. It's also hard to read, and a lot of the time the point of the message changes by the time the "thread" unravels.

Type out a single coherent paragraph of text. Break it up into multiple sentences or lines if you want, but keep it in a single message. That way you're minimizing clutter and noise. If you want to send 20 screen-shots, zip them up. Nobody wants to scroll through 3 screen-space-heights worth of vertical phone backgrounds.

As a bonus, as you're writing out these long messages, you might answer your own question. This happens to me daily. By the time I'm on my 3rd line of the message, I realize that I can either figure it out myself or that the answer was simpler than I thought.

Slack is not an issue tracker

Can we burn this one onto the Slack sidebar or something? If your company is already using a project management tool like Trello, Jira or Redmine, there is zero reason to report an issue straight into chat. You've got the right tool for the job, use it.

Yes, something may not be clear. Yes, you might not be sure it's an actual issue. Yes, you want it done quickly. But you still want your other projects to keep moving. "Slack tasks" quickly bury a team in "minor urgent sidetracking" to the point where the issue tracker loses it's purpose. Anything worth reporting is worth reporting in the issue tracker, and discussed, elaborated or closed there.

Chat is not a replacement for a call

Here's a little exercise for your. It has to do with timing. The next time you need to "discuss something real quick", take note of the timestamps of the first and last message once it's done. I bet you that you're looking at something like 8 sentences spread out over 10 minutes, or about "1 sentence per minute".

And during all of this you can't get anything done. Or maybe you can, but you risk messing up, due to lack of concentration. You're effectively blocked for that time, until the conversation wraps up. Compare this with a call in which you could get the point across in 2 minutes, and take the spare 8 minutes to provide more needed information. And once you hang up you're not left wondering if you're going to get another message before you go back to your code editor.

Anything demanding your attention now better be important

Chat is asynchronous and should be used as such. The problem arises with the default Slack settings and behaviours. You hear the notification and you run to see what's up on the off chance that it's important. 99% of the time, it's not.

And if you have those browser pop-up notifications enabled, I wonder how you get anything done during the day. Unless your attention is needed right this very instant then it's not worth the interruption.

Also, when did this become the norm:

"Hey, I just sent you an email, let me know once you read it."

10 times out of 10 it's not urgent enough to warrant that message. They'll see it when they see it. And they'll respond once they have a response ready. At least email doesn't have any pretence of being real-time.

Ways to retain your Sanity

Now that I'm done complaining, here's a list of ways for your to minimize interruptions.

Kill the notifications

First things first, update all the channel notification preferences to "mentions only". There's no reason for you to be notified for every message in there.

Also, since you can't really do this for private messages, teach your team/company to use public channels more often than private messages. Also, teach them to not tag you unless it requires immediate attention - you'll see it when you see it.

Oh, and disable the browser pop-up notification, that thing shouldn't exist in the first place.

Establish some ground rules

There are a few very simple rules you can share with your Slack team to minimize interruptions:

Try and group your chat messages into fewer bigger messages, to reduce notifications.
Don't @ someone in a public channel unless it's urgent.
If you're replying with an "Ok." or "Thanks!" a few minutes later or more, use the emoji reactions instead, to acknowledge the message.
Again, use public channels more often than private ones.
If you have more than 2 questions, best schedule a short call.

Introduce Zen Hours or Zen Days

Ok, this ones my personal favourite. There's a DnD mode in Slack, which Snoozes your notifications - even the private message ones - and it's awesome. In the event that the building is on fire, the sender can "break through" your DnD mode to get the message to you, but most of the time they won't feel the need to.

Now, to not be constantly in DnD mode, as the company probably needs you available and reading chat from time to time, you should establish certain "Zen" chunks of time.

Here at Pathway, we do a single Zen Day per week, but you might be able to get away with multiple ones. Or maybe do 3 Zen Hours each day.

What this means is that your DnD mode is on, and everyone knows not to send you Slack messages at that time, unless it's important. This works better with company buy-in, but in reality, you can get away with just using DnD for bigger chunks of time anyway. Your brain will still have you checking Slack from time to time, but now it's on your terms instead of it being an interruption.

Bottom-line

Slack is not a bad tool, but we as a society are still not sure what a proper Slack etiquette is. We don't understand what our message does on the other end, nor do we understand the cost of interruptions. As more is done on the topic, and we get saner chat defaults, things are going to get better, but until then: Snooze your Slack.

Resources:

MonkeyUser.com comic.
CommitStrip

What Programmers Can Learn From Starcraft Pro-gamers

Nick Cinger — Tue, 13 Feb 2018 14:50:56 +0000

Had to re-read that title a few times? Yeah, me too.

Starcraft is a big Esports game which has it's competitors put out crazy amounts of coordinated keyboard mashing to out-mash their opponent. The main metric defining the damage they're doing to their keyboard is APM, or Actions Per Minute.

APM tells us how many mouse clicks and keyboard presses the player is doing per minute.

The average Joe will be doing around 100 APM, and while it's not the only indicator of player level, it's still a decent metric. The best of the best go upwards of 300 APM, with some going over 400 APM, especially in intense micro battles.

To give you an idea of what that means, the average person that can type on their keyboard without looking at it is going to be doing between 100 and 200 characters per minute. Now, take a look at this guy:

Take into account that the 300+ APM is used to manage multiple simultaneous in-game battles, as well as the players economy, and you'll realize that it's a lot more than just random button mashing.

Getting up to those kinds of numbers, and making those numbers win you tournaments requires a lot of practice.

Programmers and Starcraft players spend a lot of their time on their keyboard, and while the key mashing speed is not comparable, there are a few other parallels that we can draw.

Keyboard shortcuts up your game

The most glaring difference between someone just starting out with a computer and someone with more experience is the ratio of mouse to keyboard usage. Technically, you can play Starcraft with just the mouse, but realistically, the more you use keyboard shortcuts, the better your overall performance will be.

In Starcraft you can group your army units so they're easily selectable with the numeric keys. You can do the same for your production and research structures. Otherwise you'll be using your mouse to move the game camera, then to select the units or buildings, to then pick what to build or do with your mouse. Add that other actions like attacking and spell-casting, and you're spending a lot of time moving your mouse across the screen.

To an experienced player this is painful to watch. It's like when you're watching your computer-challenged parent copy files:

"OK, I want to copy all the photos in this folder, so I click in the top left corner and start dragging." scroll scroll scroll "Gosh darn it, I didn't mean to pick this last photo, let's start over." scroll scroll scroll

Yes, it's that bad.

In programming, it's the same if you're moving through your files, cycling tabs, saving files, running builds etc with just your mouse. By switching to your keyboard, you'll save seconds on each of your actions. And while these may add up only slightly over time, more importantly they let you focus on the work you're doing. This is why some programmers are switching to Vim and giving term keyboard warrior a new meaning.

Creating muscle-memory for keyboard shortcuts let's you focus more on your code than on navigating the UI of your editor.

Consistency is key

If you're looking at getting better fast, you need to practice every day. Most programming beginners make the mistake of taking big breaks between code-learning sessions.

For example, if you take a break for an entire week, you're going to outright forget a lot of stuff you've learned recently. You need to keep learning every day, even if it's just for an hour or two. Of course life gets tends to get in the way but you should be actively fighting to create a consistent schedule.

In Starcraft this usually means that you'll start forgetting the more minute details of the strategies you want to use and you'll start making several mistakes. This adds up and may end up costing you the match.

In both cases, this doesn't mean you can't mix it up a bit. You could be reading strategy guides, blog posts or discussion forums to stay in the loop. Or you could watch others code or play in real-time - there's actually a lot of programmers streaming on LiveEdu.tv, although it's going to be a tad less exciting than watching someone play your favorite Esport.

Team Houses keep you motivated

Whether you're just learning or are already a professional (ie. your keyboard mashing is earning you money) surrounding yourself with like-minded people is going to help propel you forward.

In South Korea the concept of a Team House is relatively common in Esports. It's basically a frat house with less jocks and more nerds. The idea is that you're practicing Starcraft day-in and day-out, making it a full-time thing.

Of course you can do this at home, but you're going to be spending a lot more time explaining to Mom that "I can't pause, it's an online game!".

Even though you'll be surrounded with friends, you'll be less likely to just slack-off, because, at least theoretically, they take their work seriously and this is going to put subtle pressure on you to stay productive and not open YouTube after 5 minutes of practice.

Coworking is the Team House equivalent for learners and remote workers. Even if they're not all programmers and it's a mix of different types of work, like design or content-writing, the important part is that you're surrounded by people that are there to stay productive.

As an added bonus now you have someone to play a few casual games with, whether it be Starcraft or Ping-pong. You can let yourself unwind a bit and still be more productive than you would be sitting alone at home.

Conclusion

While Starcraft skillz don't translate directly into programming there's a lot any coder can learn from the habits of the pros. And the next time your CS teacher catches you playing Starcraft in Computer class, just tell him you're leveling up your APM!

References:

Stay tuned for a follow-up post! Follow me here or on Twitter, @nebojsac.

You are not your Framework

Nick Cinger — Wed, 31 Jan 2018 08:30:32 +0000

There is a worrying trend developing among web developers that should be raising red flags in the community. We've gotten so good at promoting Best Practices^tm, Best Frameworks^tm and Don't Reinvent The Wheel^tm, that we forgot to let new developers make their own mistakes, and learn the ins and outs of webdev in the process.

Code boot-camps, intern positions in companies and online forums alike have drifted towards pushing the greenhorns to "just use the framework". Sure there are tedious things they shouldn't be re-writing on every project, like authentication, input sanitizing and cache handling, but they are missing out by not learning how it's done. Except for encryption: Don't roll your own crypto. Unless you're this guy.

And I get it, you're new, time is short, you want to skip all the checkpoints and go straight for the finish line. So now you're looking at job postings, online discussions and blog posts to find out which is the best framework to use. Depending on the current year it might come down to a choice between Laravel and Symfony, or maybe CakePHP, Yii and Codeigniter. So now you have your framework and you steam-roll through the "build a blog" tutorial within a single weekend. You venture online proclaiming that you know all there is to know about this so-called MVC paradigm.

"I just put my HTML/CSS _here, my database stuff there and my session stuff all over the god damn place, and _look Ma', I'm doing MVC!".

Great, this is already a lot better than that mess of includes and requires you had with footer.php and functions.php on every damn web request. Now all you need to do is tell the framework what you want, and poof you've got some instant ~~bloat~~ feature on your hands that does stuff you don't see and don't even try to understand.

A week later, you have the Framework^tm sticker, it's on your CV listed under "proficient in:" and you're calling yourself A Web Bagel Meister.

And this is perfectly fine. If you're 1-2 years into web development. There's nothing wrong with putting on some training wheels. But for goodness sake learn to ride a bicycle after a while - don't just title your portfolio "Tricycle Expert".

Red Flags for the Hiring Process

It's your right to look for the kind of work you'd like to work on. It's also a reality that a lot of what's out there is going to be work on existing, potentially legacy systems. And there's a good chance it won't be written in Framework^tm.

If you're shown a piece of the system and asked how you would improve this code-base, and your immediate response is "I would rewrite it all into Framework^tm" you're going to get a polite smile, a nod and your printed CV in the bin.

Your favourite framework is not the solution to everything. I know you have a shiny new hammer, but we're not going to let you chop wood with it. Re-writing a multi-year code-base in your favourite framework is NEVER-EVER a valid business decision.

There's a case to be made for migrating an old system by writing new features in a separate fresh codebase, and gradually moving bits and pieces out of the legacy system. But I've recently had too many interviewees and new hires think that re-writing a decade-old project into the current hotness is a good idea, to consider it a slip of the tongue.

I've asked people to do simple stuff, like loop over results, write to a file and use an existing Model and findById() method. The interviewee with 5+ years of PHP experience reached directly for classes and helper functions from their favourite Framework, even though the task was explicit in making the new Class decoupled. As if there is something inherently dirty in using file_put_contents().

"But how can I get out of this and move on with my skillset? Tell me it's not too late senpai" - you sob as you cling to my kimono. It's not too late, and here a few guidelines:

Don't be a Framework^tm Developer

Be a Developer, with MVC framework experience, and hopefully some vanilla PHP to back it up. Learn about Design Patterns. Read "PHP the Right way". Do not participate in Framework Wars. I repeat, do not participate in Framework Wars.

If you get all defensive every time someone critics a tool you use, it might be time to step back and rethink your position.

Write decoupled code

This will force you to actually learn OOP PHP. No, you're not giving up all the niceties of the framework by doing this - you're writing cleaner, more maintainable code that's easier to test. Do it, you'll thank me later. And if in 5 years you decide to rewrite it in your Favourite Framework+1^tm anyway, this will make it a lot easier.

One of my biggest "A-ha!" moments was when I realized that I'm allowed to actually create my own folders and class types within the framework directory structure. You mean I can write my own CleanerProxyFactoryGenerators, and I don't have to cram it all into Controllers or Models!?? Bye bye Fat Models, hello Services!

Get under the hood as often as possible

If you don't learn how the magic works under the hood, you're at risk of being bitten by weird bugs, or being stuck in debug hell for days at a time.
Sometimes you don't really need that framework method, many of them are just bloated foreach loops or array manipulators. Yes, it may cover more edge-cases, but it's open source: take a look and make an informed decision on whether to use it.

If you're blindly doing things the Framework Way^tm, you won't understand the performance cost associated with it. There is nothing inherently wrong in using vanilla PHP/JS/Ruby to solve the problem, and there's a good chance that it'll solve the problem an order of magnitude faster.

Continue learning and trying new things

It's going to be hard to become an evangelist for a single framework once you realize that it's not the end-all to web development. More than likely, it does a lot of stuff right, and a few things wrong. This becomes more apparent once you know frameworks with different subsets of correctness and wrongness.

All in all, as long as you're aware that there's a problem, you can be helped. It's a natural part of learning, but as such it's a stepping stone that you need to move past.

^Unless ^you're ^using ^CakePHP, ^in ^which ^case ^you're ^golden, ^and ^don't ^need ^to ^change.