Category Archives: software

Have you crossed the midpoint in your career?

There is something that has snuck up on me. When I stopped to think about it, it became clear. There is a point in your career when you cross this “midpoint.” I remember Day One of my first job as a professional software engineer.

I had already written little scripts, apps, and other hobby projects. But this was the day I was building stuff for my livelihood. The day when I had to start steadfastly listening to others, and doing what I was told. Sounds scary, right? Well, not really. I guess I was too gung ho. And the people that hired me did a great job at hand holding. Nevertheless, what I know today and what I knew back then are starkly different.

What is the midpoint? I like to think of every person out there writing code on a spectrum. People on their first day start at the bottom. Then slowly, but surely your knowledge and experience causes you to rise. On your Day Two, there is someone else having their Day One. At a certain point, you cross the halfway mark, or the “midpoint.” Congratulations, you arguably know more than half of the other people in the your field.

This isn’t an article about arrogance, or how I’m better than you. No. This is recognizing that the things you learned in college have benefit, but we all gain new talents and experience every day. And your responsibilities change.

On Day One, your responsibility may be to test someone else’s code. (That was mine!) But at a certain point, perhaps after you’ve crossed the midpoint, your responsibility may be to help others. To teach, lead, form communities. Or to take the reins of a project where there is zero management and guidance. Those that are on Day One aren’t equipped to do that.

An honest recognition of where you “are” can make you realize that signing up to speak at a conference, hosting a JUG group, leading an open source project, or offering to run a project with little more than a single sentence for a high ranking manager in your company.

It’s also a keen time to visit places like Stack Overflow and answer questions. And remember to extend grace to those that are new and seeking to grow themselves. Some people call this giving back. I’ve never been a fan of this expression. I prefer to think of it as sharing what you have learned with others.

The magic of software development

People think I have a magical talent. It’s funny seeing the difference between what I know and what others think I know when it comes to debugging stuff.

Simply put, I know how to tinker. I have clues, hunches, and insights. But that stuff is useless to a developer not willing to roll up their sleeves and engage in ten solid hours of trial and error. Often times, that is what makes or breaks a demo or a customer feature.

clock-with-a-questionDid I mention ten hours? Sorry, I meant ten days! Or sometimes it takes ten weeks to push your way through a mountain of integration, setup, and labor. Whatever it takes. But it isn’t solved by “knowing the answer” when you sit down at the keyboard.

We software devs work in the strangest field. First, we pursue a degree in either Computer Science or Computer Engineering. Ever seen a scientist and an engineer talk? Polar opposites. So what is software development? A science or an engineering trade?

My buddy Russ Miles has likened this to R&D, since there is no real sense of “can you have that ready in a month?” Building a bridge between two fixed endpoints is much easier to estimate than “can we have this website operational by next year?”

Experiment: Find your most non-technical friend, and ask them if they have a clue what you do. Then try to clarify when they say “no.” And try, and try, and try.

Solving software problems can seem foreign to both science AND engineering. On many days, it’s just tinker, tinker, tinker. And yet, our world’s dependency on it is growing.

HamletSoftware is really just organizing a set of patterns to respond to information. We need certain behaviors triggered automatically, and software is a giant stack of rules meant to handle that. As we collect more information and link more things together, the need to manage this grows.

A good visual of what software really entails is a hologram. Remember that limited-response hologram from I, Robot? We are just tinkering to put together a set of rules to better manage everything around us.

This requires tinkering, not magic. Good ole elbow grease is sometimes the best tool.

The value of backwards compatibility

springI was listening to Episode 6 of the Nash Dev Cast as they spoke about bitrot, of how stuff degrades as the whole Internet upgrades around you. It really reminded me of the inestimable value of Spring’s approach to backwards compatibility.

Something that is almost unnoticeable is that the Spring Framework and its entire portfolio has backwards compatibility. Bumping up the version in your project when a new release comes out is a no-brainer. They just don’t break stuff. You may get alerted to deprecated features, but the JavaDocs will kindly direct you along the upgrade path. Moving from Spring 1.2.8 -> 2.5 -> 3.0 -> 4.0 has such little cost, that people are eager to jump to the latest.

junior-devAs a junior developer, this kind of thing doesn’t really resonate. And not because you are somehow bad. No. It’s simply because you don’t have as many war stories to share over upgrading other libraries, and having major breakage. Senior developers at conferences will share a beer and discuss some crazy upgrade that got started, and a breaking change they were forced into turned a 2-day upgrade into a 3-week effort.

Even as a senior developer who recognized this feature of the Spring portfolio, it wasn’t until I joined the team and proposed changes, that I learned of the technical challenges this team faces to enforce backwards compatibility. It really rose to the surface when I heard Juergen speak about Spring 4 being “Java 8 ready” but still working with Java 6. With scrunched eyebrows, I leaned closer as he spoke during the 2013 Birds of a Feather at SpringOne how the framework would certainly support Java 8 features, but still operate on Java 6.

That perplexed me. How could a framework take advantage of things like Optional yet blink “no problem” if you used Java 6? Digging in, I learned not only how to build a JAR file with Java 6 specs but neatly keep Java 8-based API calls inside Java 8-flagged classes that were only loaded when Java 8 was the loading engine. And I learned how hard this effort was.

I already respected the Spring team and the programming model they had developed. But this level of technical expertise combined with forward thinking plans to start ten years ago and maintain to this day, was quite impressive.

So, listening to podcasts about JavaScript open source modules, sifting through and evaluating products, and getting “left-padded” at times, made me snug and comfortable in my decision to bring onboard the Spring Framework years ago. Their decisions to invest so highly in the community have paid dividends I have no idea how to tabulate.

In defense of leftpad

Given the time I’ve had to think about the whole leftpad controversy, I have to come to the conclusion that leftpad was PERFECTLY FINE with its decision to build a module with only eleven lines. (As to the brooha over unpublishing and then being forcibly republished by npm, that is a different topic.)

leftpad wrote code anyone with half a brain should be able to write

laptop_chimpThat must be the biggest sentiment I’ve heard. Blogs, podcasts, and other forums have thrown out this strong criticism of leftpad’s code. It’s best summarized as “have people forgotten how to code?”

Gee, leftpad getting unpublished broke React.js, Babel.js, and how many other systems? If those impressive projects saw value in leftpad, sounds pretty big of me to judge them all for making such a foolish decision. After all, that’s what I’m doing, right? I’m ascribing judgment for using it.

Let me be clear: I haven’t actually READ leftpad’s code. I’m not defending the physical lines of code in that module. The market spoke and accepted leftpad. I am defending the choice others made because I myself haven’t invested the time to make a better choice.

leftpad wasn’t REALLY used by React.js, etc. It was just a transitive dependency

2001This one doesn’t sit right. It’s kind of like saying, “React.js is good. The people writing it would never need something like leftpad. They just got caught by some intermediate dependency.” Can you smell the disdain?

If leftpad was used by an intermedia dependency, and that is what all the big weights used, then the transitive property applies. Not only has the market said leftpad met needs, but the intermediate dependencies are just as valuable. See what I did there? Transitive dependency, transitive value.

leftpad isn’t actually the best way to do what it did

Kaypro_in_Israel_1984Here is where it gets interesting. This is what I hear from those that have spotted the transitive link. Can’t criticize React.js, because they didn’t REALLY use leftpad. Let’s look elsewhere.

People have been singing the UNIX tune of “do one thing and do it well” as microservices arise. Defenders of leftpad point it out as a composable function, adhering to the UNIX philosophy. But if you can tear out “do it well”, then leftpad doesn’t qualify for this concept. Hence, leftpad was a badly written composable function.

Sorry, maties, but as software engineers, we seek out solutions on a daily basis. And in the land of open source, we constantly make “build or buy” decisions. Whenever someone asked me, “what is an engineer”, my answer has always been, “we find a good enough solution for the problem at hand.” We don’t seek perfect answers, because we don’t have an infinite budget.

For a LOT of people, leftpad was good enough. They could have written a better solution, but they could also have written a better solution for LOTS of other modules. Imagine the cost of perfecting every single thing you use. Or how about this: imagine the cost of tens of thousands of developers writing an equivalent to leftpad. Perhaps 15 minutes tops, but multiplied by 10,000 and your talking 2500 hours of effort. Doesn’t that defy the concept of open source?

What’s next?

imageI know people that don’t like certain tools out there. They have written their own version of things. At first glance, there’s underscore and lodash. These two libraries essentially do the same thing. But one project was not satisfied with the other project. Hence, they built a fork and whole community around it.

These are people I respect, because they took the time to evaluate the current state of affairs and write their own solution. When I go pick from one of these two solutions, I can find out the basis of one or the others. Has the bulk of the JavaScript community picked one of the other? Or is it a big split? These are factors in choosing.

I can spend all my time building everything from scratch and live under the haughty label “I know how to program. I’ll build it myself.” But we already have a term for developers like that: “Not Invented Here“. Some people will only touch code they themselves wrote.

If you actually spent the time to read leftpad’s code, then used it or decided otherwise, that’s fine. But don’t go around criticizing others for using leftpad. After all, you’re criticizing the choices of MANY others.

Good developers take breaks

Boring PresentationSomething that has become crystal clear since I joined the Spring team is how important it is to take a break. Good code happens when developers take breaks.

Of course there are times when I find myself working solid until 8:00 pm or later. But I try to make that the exception rather than the norm. Most of the time, I’m pulled away by my kids coming home from school. In fact, I’m often annoyed at stopping a minute early.

STTNG_pinballAnd yet I’m astonished at how many perplexing problems I’ve solved by simply stopping, doing something else, and **BAM**, the answer pops into my head. Sometimes within minutes, sometimes the next morning while putting shoes on one of my kids. Those are the moments when I remind myself that developers take breaks. I consider that payoff for having stopped early.

This phenomena is well know. In fact, you’ve probably heard of it. I also so it addressed keenly at a writer’s conference last year. Your subconscious is still working on the problem whether you are or not. Sometimes, when you aren’t actively trying to fix it, your noodle is freed up to look back at what you did, what you’ve read, and other things.

devnexusWhile chatting with a teammate of mine at DevNexus, he expressed that if he hadn’t taken various breaks, gone for walks and thought about the architecture he was designing, the project he was striving to build would never have happened.

HamletReflection is a critical component. My martial instructor often taught “visualize, visualize, visualize.” It’s a mechanism to put your mind on the subject, even when you’re not actively pursuing it.

The key thing is telling yourself to take that break. To pause. To stop and not burn the candle at both ends. If you work that hard, your subconscious will be on the ropes. Those extra ideas that can often succeed when you may have failed all day, may not come at all. It’s a big leap I know, but give it a try.

#opensource is not a charity

clock-with-a-questionLogging onto my laptop this morning, I have already seen two tickets opened by different people clamoring for SOMEONE to address their stackoverflow question. They appeared to want an answer to their question NOW. The humor in all this is that the issue itself is only seven hours old, with the person begging for a response when their question is barely three hours old. Sorry, but open source is not a charity.

gordonBatPhoneIf you have a critical issue, perhaps you should think about paying for support. It’s what other customers need when they want a priority channel. It definitely isn’t free as in no-cost. Something that doesn’t work is opening a ticket with nothing more than a link to your question.

question-not-answeredOpen source has swept the world. If you don’t get onboard to using it, you risk being left in the dust. But too many think that open source is free, free, FREE. That is not the case. Open source means you can access the source code. Optimally, you have the ability to tweak, edit, refine, and possibly send back patches. But nowhere in there is no-cost support.

pivotal-ossIn a company committed to open source, we focus on building relationships with various communities. The Spring Framework has grown hand over fist in adoption and driven much of how the Java community builds apps today. Pivotal Cloud Foundry frequently has other companies sending in people to pair with us. It’s a balancing act when trying to coach users to not assume their question will be answered instantly.

helpingI frequent twitter, github, stackoverflow, and other forums to try and interact with the community. If at all possible, I shoot to push something through. Many times, if we’re talking about a one-line change, it’s even easier. But at the end of the day, I have to draw a line and focus on priorities. This can irk some members not aware of everything I’m working on. That is a natural consequence.

Hopefully, as open source continues to grow, we can also mature people’s expectations between paid and un-paid support. Cheers!

P.S. For a little while longer, there is a coupon code to Learning Spring Boot for 50% off (Python Testing Cookbook as well!)

Banner (LSPT50)

Why software development is not for everyone

Have you ever had gobs of fun hacking away on a computer? Noodled with a piece of code that you discovered in the afternoon, and here it is, 2:00 a.m.? That’s a sign you may be a computer geek. That’s all and good, but the question that may come before you is, do you want to make this your dream job? Your career? Watch out, though. Software development is not for everyone.

mr_potatohead-300x190I fear that some people may be getting into software development because computers are now hip and cool. And the money is good! I remember a time, several years ago, when I saw the corner turn in how computer geeks were no longer the goof bots found in Wargames, but instead, totally righteous dudes.

What was that tip off? A TV ad for liquor which showed “Jim from IT” partying just like everyone else. TV ads are a bellwether for trends, because that write them are constantly polling groups of people to see what will resonate. When IT people had entered the main fray of the party-going crowd and were seen a force to be reckoned with (err…a force to be advertised with), then game over.

The side effect of anything going mainstream is that others, who have no deep seated desire to submit and review pull requests on vacation (for the record, I’ve actually done both at Disney World. Top that!), will still flock to the field since its cool, and there’s money to be made. Am I saying that to get ahead, you must be a workaholic and eschew your family? Not at all. What I’m saying is that computer geeks that are in it for the challenge and not just cuz it’s cool can’t help themselves but do what i just described.

So far, I’ve talked about hacking on bits of code at odd hours in odd places. But here is the real test, the true gambit to see if deep down you really are a totally righteous hacker dude: do you go after the most boring, challenging, mind numbingly difficult problems until the code surrenders its secrets to you?

Do you go after the most boring, challenging, mind numbingly difficult problems until the code surrenders its secrets to you?  –sign of a righteous hacker

I have been working on something for several months that is coming to light in less than two weeks. (Stay tuned!) For MANY hours/days/weeks, every time I tweaked one line of code, I had to restart a microservice. That microservice would take, on average, two minutes to load up its data set from a remote system. Next, I went to another tab and clicked on a button to launch a process, and wait to see if my system detected it and processed it correctly. Got that? Edit one line of code, wait five minutes for the results, then debug the outcome. Rinse and repeat.

aaarrrggghhhAaaarrgggghhh!!!! <— that was my reaction on many days. And my followup was, “thou shalt not defeat me!” My street cred was at stake, and my own internal desire to beat this system into submission were there as well.

Suffice it to say, trudging through this task is not for the faint of heart. Software hobbyists need not apply.

I’ve always hated the expression “9-to-5 coder.” It’s meant to imply people that only work on the clock, and don’t work late hours, etc. In general, I do that as well. At times, I have to alert my family that I’ll be putting in extra hours (especially the month before SpringOne each year), but in general, I have found that working smarter, not harder, and thinking out solutions before slinging code can make things more efficient.

So I prefer to think of developers not based on the hours they work, but rather, are you a hobbyist or a diehard coder? Diehard coders will take the most ruthless problems and dig, dig, dig, dig, and dig until the answer is found. They are willing to take many hits, submit faulty patches, and screw things up big time, because the end game is important. Version control is our tool to save us from screwing things up, not timidity. Are you a hobbyist that fears making a big change? Or are you a diehard hacker ready to show your handy work to others?

I remember this topic coming up when a website popped up offering bounties for people to solve problems. This was rightly criticized as encouraging people to go after easy–to-tackle issues, or selecting issues that carried much public praise, like UI mods. But serious, professional hacks will take some of the most invisible things (like a 300ms slowdown) and go to extreme ends to unearth what’s wrong. Imagine trying to get ANYONE to pick up that issue for a bounty.

If such tasks sound outrageous or tedious, no problem. I understand. You are hobbyist. Nothing wrong there. But if you’re ready to dive into the slimiest mud bath of code, smile. You are rare.

We won’t own our own information until we do

Not a week goes by when I hear some story about people displeased with how their own content has been misused. People gripe that entering stuff into Facebook no longer belongs to them. Other people copy-and-paste such stuff into other places. Things go “viral”.

I chuckle at how so many politicians act like we are still in a pre-YouTube era. They say and do stupid things in front of small crowds. Someone inevitably grabs a clip with their phone, posts it to YouTube, and it blazes across the twittersphere. Or someone makes an accusation or promise, and in minutes, a video interview from fifteen years surfaces and gets re-posted to the interwebs.

The truth is, there should be some sense of ownership of our content. If I post something, somewhere, I understand people’s desire to hold onto it and have the last word. Unless you speak it in front of someone else, and they make an independent copy, it makes sense that you should be able to effectively delete your posting. What you said and the repercussions thereof are your own issue to deal with.

The truth is, we can’t “own” anything we write anywhere unless we can wrap it using encryption technology. Essentially, if every blurb you posted was an encrypted bundle, people would have to come to you to decrypt and read it. Throw away the key, and that blurb is gone forever. For certain avenues, like everything I write on Facebook, I can understand retaining a hold on it. And if someone wanted to copy-and-paste it, it would be really nice is the encryption traveled with it. Copy it 1000 times, as long as the wrapper is in place, and you still control it.

But there in lies the rub. Encryption technology has proven far too difficult for mass consumer adoption. Just now, the web is headed towards moving all web traffic from HTTP to HTTPS to prevent intermediate snooping. This should have happened years ago. But the next big leap would be encrypting all email traffic. With people losing laptops and thumbdrives, lots of security breaches have happened. If ALL email was wrapped in encryption, privacy would be a much stronger concept. But the process of doing that is arduous. Exchanging keys, keeping your private key secure, and then entering passphrases all the time is a hassle.

Take that concept and apply it to every other medium in which you write something. Even this blog entry! It’s safe to say, such a concept won’t come to pass until it becomes effortless to prove on a terminal you are who you say you are, and to lock and unlock keys suitably. Seeing the web move to SSL is a good sign. I just hope we can migrate along these paths faster than we can figure out to integrate stuff together smoother. We must own the pipes and the traffic our data rides along.

Continuous Integration, or What doesn’t kill us makes us stronger /cc @ewolff

I have gotten onboard with using Travis CI for several projects. It is really cool. You can see some badges listed here:

  • Spring Social Ecobee Build Status
  • Issue Aggregator Build Status
  • Drone Aggregator Build Status

(You can go ahead and click the icons to see more)

Having a constant indicator of something passing or failing is incredibly handy. But upon reflection, I remembered having built just such a system over fifteen years ago.

A long time ago, in a cubicle far, far away

Back in the dawn of my career, I wasn’t granted the privilege of coding features. Instead, I wrote tests for other people’s features. This was a time that predated automated testing and developers being on the hook for their own stuff. Instead, test teams were employed to attack the code with a battery of written procedures. To warm me up to the system, I unit tested other people’s stuff. I had cute test cases that would print out the code’s outputs and my own expected outputs. (Why I didn’t make the final link and simply assert those two values being same I’ll never know). But my tactics of having visualize printouts where these two values would appear right next to each other on the console inspired others to do the same. I spotted another tester quickly adopt my technique. First instance of professional flattery I can remember. It goes to show that when you have to do testing all day, you come up with ways to check off the box faster when values match. (Again, no idea why I didn’t let the test compare the values. Newbieness?)

I shared a cubicle with another junior developer. His job was to run handle the CM process. At the time, our application took ten HOURS to build. You heard that right. Thank you ADA. We also used an ancient form of version control. I call it “one dimensional” version control, because there was no such thing as branching off of master. There was a single, monotonic set of version numbers. When people needed to check out a copy of the system, they came to my cube mate to clone the baseline, which was really what people today might call a version snapshot. That’s because copy the entire baseline from a version snapshot and doing a first, clean build, took ten hours. No senior developer’s time was worth it to do that process themselves. (Incidentally, this is the reason features were HUGE and took weeks or months to complete. If it was going to take ten hours to cut a new workspace, might as well cram as much functionality as possible into it, ehh?)

That which you support you may one day take over

The side effect of sharing this cubicle was that i became his backup. So, I learned how to do his job. Perhaps you can see where this is going? I ended up taking over his job. He moved on. Granted, he had graduated from college with a degree in English and truly sought a career as an author. This was just his daytime job. So he took the path of least resistance. I had a different thought process. I strove to speed up everything possible.

One of our processes involved moving up the “stable” version of things. We had a weekly meeting where my manager would review completed features, and essentially give the green light for to move the “master” position of things. FileX.ada would move from version 4 to version 8. FileY.ada would move from version 15 to version 19. You get the idea. Very expensive and subject to MANY errors. I hated this process. So I sought to fix.

My first Continuous Integration system

Being the script junky that I was (still a bit premature for “test-bitten”), I used that spare time of watching ten hour builds spin their wheels to craft some PERL scripts. I knew how the current batch of scripts operated. What if I kicked off the same build process, only automatically at midnight against the “master” snapshot? What if I captured the outputs in a log file? That way, everyday at 10 a.m., I could review the latest build and spot any errors. After a little chat with a sys admin (I was using a SUN box at the time), I crafted my first CRON job.

It took a few iterations of coming in and seeing if my job launched. Translation: I wrote a CRON job and came in the next morning to see if it ran. At all. Failure? Tweak the job and wait until tomorrow. Several days later, I had the job working great. I could peruse the results and alter the format of the output. Now that i was reviewing this daily report, I started to alter its format. There were key things i skimmed through to spot. To make the reading easier, I prefixed them with “!!!!!”. After a few weeks of this fine tuning, I started to filter the report to ONLY look for this tag. Finally, I added the feature that if there were no “!!!!”, then the build was a success.

By the way, this wasn’t running my test suite and verifying the code. I was too green to see that. Instead, this was simply COMPILING the code and seeing if it passed. But once I had this report in place, I crafted some queries to look at who had submitted what today we might call a “pull request”. My scripts would look at the newer versions of the files, create a snapshot copy with those changes, and do the build job. I would see the outcome at 10 a.m. If it passed, my new copy became the new “master” snapshot. If not, I chucked it and instead focused on what broke. I would take this feedback to the relevant parties and let them sort it out.

Manager’s delight

When I presented all of this to my manager, she was delighted! Pretty soon, those weekly integration meeting vanished. I had figured out a way to continuously build the system with the latest changes and upgrade things. I could start the day with running my test suite against a newer version of things. Yee-hah!

The management team extended my time on this project twice. I was clearly kicking butt and taking names in the land of integrating completed features. But I wanted to build the systems myself, not simply maintain what other had done. So the third time they asked for an extension, I turned them down. I moved on to other projects my company was hosting. But I had cut my teeth on what today everyone knows as continuous integration. Picking up skills in CRON jobs, understanding the core mechanics and ramifications of version control and change management, and seeing the benefit of automating the heck out of things had paid me back with dividends throughout my career.

Seeing tools arise that make it easier and easier to seek higher quality in software warms my heart. Create your repo on GitHub,. Link it up to Travis CI and fiddle with a few settings. Have it deploy automatically to production on Cloud Foundry. Plugin a Chat Channel (gitter). It feels like ten years ago, we were working in the stone ages. I just wonder what things will be like ten years from now.

Checking out editors

idea_sublime_atomIf there is something software developers do, it’s get real picky about tools for editing software. That’s why there are strong, almost religious debates about vi vs. emacs. I recently got fed up with TextMate for various reasons, so I decided to investigate more than my usage of vi.

I’ve included a screenshot of all three, side-by-side on my 39″ monitor. You guess which is which.

Sublime Text 3

This one I have found to be pretty neat. It’s fast, snappy, and opening up a project is a single command from my shell: subl /path/to/project

I quickly got moving when I learned there were only two key commands: Cmd-P and Cmd-Shift-P. The first is used to find files. You start typing fragments of a filename, and it quickly narrows your selection. Pick it, and it’s open in no time flat. That nicely matches Java’s one-class-per-file convention. Cmd-Shift-P is the Command Palette, which lists every available command. You then start typing fragments, and your list of commands shrinks. Then you can arrow-down and pick it, or hit the hotkey. Having a single way to find any command or file saves me from going to my trackpad and using the menus.

In the JavaDocs, HTML tags are nicely highlighted. Sometimes the color choices of Java syntax seem a tad awkward. But I rarely alter settings because I always fear either losing them, or going to someone else’s machine and not having them. Perhaps I might be able to stash them in Dropbox and soft link them in?

Another killer feature is the right-hand miniaturized layout of the entire file. Hover over it, and you quickly see where you are.

I’m still pretty new, so I haven’t learned how to open multiple tabs on the same file yet. Nonetheless, this tool is already productive for me!


After spending almost a whole day adding new asciidoctor content, my colleague Roy Clarkson hinted that I should check out Atom. I downloaded it last night and took a peek.

Nicely, Atom has the same keystroke to pull up the Command Palette. This feature sure must be popular. Right off the bat, I noticed the font size was a bit big. While it appealed to fuzzy vision, it was too impractical for the ground I needed to cover. Felt like I was peeking through a tube to see the code. So I pulled up the Command Palette and shrink the font size about five times so it approached the size of Sublime.

Opening the same file in the same project, I noticed that the color palette of syntax highlighting was a bit easier on my eyes. The contrast between bits of code didn’t seem wide enough, while Sublime’s contrast was a bit much.

I read an article pointing out how Atom is built on top of Chrome, JS, and Node, and conveniently comes with the JS toolset. Another article heavily criticized Atom’s shaky foundations which can start to magnify performance issues as you get into bigger projects. I’ve already seen a bit of this when trying to find files. Sublime just seems snappier.


To compare things in full, I switched IDEA to it’s Darkula theme and opened the same file in the same project. A third syntax highlight color palette. Great. This dark-theme on IDEA is softer on the eyes, but some of the color clashes kind of turn me off. I’ve tweeted before that I don’t get it. Yet, at the same time, I use green-on-black for Terminal and totally dig the white/color-on-black of the other editors. Perhaps if I commit to a couple days, I might get into this?

What does IDEA have that the others don’t? IDEA is a full fledged IDE. Pick a function, then find everywhere that it’s used. Editors aren’t designed to do that.

This Command Palette from the editors has encouraged me to learn how to do that in IDEA. Apparently, Shift-Shift is the way to pull “Search Everywhere”. I am trying to do more of this. I have already learned how to find files and classes as well as pull up refactoring toolbars. These are all handy features. But to speed up the action, I need to jump to the command palette. From there, you can see commands as well as learn their hotkeys. More time on the keyboard is the ticket to efficient coding.


So far, IDEA isn’t going anywhere. I need this type of stuff. I just have to keep improving my efficiency at using it. As for an editor, Sublime is ahead of Atom right now. But like my bio says, I’m always looking for the right tool.