No time to waste...

I love videos like this. I watch multiple every year. I stacked up terribly the first year: I hardly knew any of the technologies - hadn’t even heard of most. I was freelancing, and a lot of the highlighted tools weren’t necessary to complete my projects. After four years of developing on a team, however, I’m starting to make the cut.

I attribute my progression to being an early adopter. I believe in trying new tools and technologies as soon as possible. I’m not saying switch frameworks every year, but there should be a “buzz” around most of your tools and stack. That’s where you find the advancements that improve your workflow and productivity. ColdFusion, for example, gets the job done, but try finding a Vagrant box for it, or using it in a serverless architecture. Not happening. I'm pretty productive with Backbone.js, but I started using Vue.js last week. Backbone works well, but it's missing useful tooling (a cli, for example), so I have to move on; I'm always looking for better tools and methodologies.

I get the frustration with constant change. It takes time and energy. I remember learning Gulp and thinking it was serious overkill, but I kept at it because better devs were using it. Eventually, I got the hang of things, and now it’s one of my go-to tools. It appears, however, Gulp is now out, and Webpack is in (that’s based on more research than just this video, by the way). So now what? Am I supposed to abandon Gulp and move on to Webpack, even though Gulp works just fine?

Short answer - yes. There’s nothing wrong with waiting a few months or a year before trying a new tool, but I’ve noticed a problem with devs who tend to take this approach: they never end up adopting anything. The time is never “right,” or they wait so long that newer tools emerge. Of course, they then wait-and-see with the newer tools - stagnating further. That’s not a recipe for success, in my opinion. I take the opposite approach and go for it a.s.a.p.

It's important to know your style, and to be clear about it when joining a team. Working with “slow” people is difficult, when you’re aggressive about using the latest and greatest. It’s equally frustrating working with people who use new tools every project, when you want a “stable” environment. Choosing a team with the right outlook is critical to job satisfaction.

Oracle Code Chicago... I'm going...

For developers in the Chicago area, I’d like to put Oracle Code Chicago on your radar. It’s next Tuesday. I’ve decided to go. Initially, I was on the fence because I’m not a Java developer, and I don’t work heavily with any Oracle products - at least not enough to warrant interest in a conference. I’m pretty busy with a sprint, and not really interested in much other than finishing it. But I think it’s important we support events like this. It’s free, relevant, and shows industry leaders there’s a serious development community in Chicago.

We want these companies to know we’re here and active. Anyone seen what’s going on with Amazon’s second headquarters? 50,000 jobs gets my attention. Chicago is on the list, by the way! And that kind of shit attracts top talent. So you get more, and better jobs, with better networking opportunities. It’s a cycle that benefits everyone, but it requires participation. Companies need the turnout numbers.

That’s just the start, though. What if companies like AWS, Salesforce, and Google started regularly throwing smaller, free conferences? You could learn more about the technologies that interest you, for free, and with other interested devs in the area. Sounds promising to me, and I bet it could happen. We just need to prove we have the audience for it.

Anyway, I’ll cut my radical speculations short. If you decide to check it out, maybe we’ll run into each other. I’m interested in the following tracts:

• Offline-first Apps with WebComponents
• Modernize Your Database Development Process with Open Source Tools
• Serverless Everywhere with the Fn Project
• Resilient Microservice APIs with REST and API Gateway

I’ll probably tweet what I attend while I’m there, as well.

Design Blues...

I’m spending more time designing than writing code now. It’s a big change that has resulted in better code. I’ve never been required to this before - not even now - but I want to develop the habit of writing unit tests. My prior approach has been to immediately start coding and testing. Keep going until you’re done. You get working code, but it’s not always good. Practicing TDD has helped me see that. I’m saving time and getting better results.

The downside is that I hate the process. I’m so used to equating “coding” with work and learning that evaluating design choices seems a little lazy and unnecessary. The whole time I’m designing, I’m anxious to finish - not enjoying any of the process. Apparently I prefer debugging. I guess it makes sense: the fun part is making something work.

Hopefully  this will be a week of actually coding, but we’ll see. On another positive note, I discovered a pretty good JavaScript library: Fine Uploader. I’m using it in the feature I’ve been designing. It’s been pretty easy to use and configure, so I thought I'd share...

New Tools for the Toolbelt

If you’ve never heard of Chris Hawkes, check him out. I listen pretty regularly. Like a lot of guys you find on YouTube, most of his content is geared towards new developers. He still manages to slide in a few advanced topics, though. Be warned: if you’re sensitive to profane language, he may not be for you. He can sometimes be vulgar. It doesn’t bother me, though; I find it funny.

Anyway, I was listening to "Is CoffeeScript Dead In 2018?," and he made a good point - the gist of which was to be strategic about where you invest your learning time. In other words, don’t feel pressured to learn the newest technologies, as soon as they come out. Sometimes it’s better to just wait. He uses CoffeeScript as an example. Apparently it’s dead.

I’m relatively new to development (3.5 professional years, at this point), and haven’t worked on any CoffeeScript projects. As a result, I don’t know much about it. I am preparing to adopt TypeScript in a coming project, however, which is a similar technology. For those unfamiliar, TypeScript basically adds data types to JavaScript. After watching Chris’ video, however, I started having concerns. TypeScript requires a dedicated maintenance team. What if that team dissolves? What if Microsoft goes proprietary? What if a better implementation of data types is already in the works for a coming release of JS? Crazier things have happened…

I shared the video with a colleague of mine - a guy I trust and respect - who is in the TypeScript-is-fine camp. He allayed a few of my concerns, but he’s still a relatively young guy. He hasn’t had time to see an industry evolve. I have. I’m now a developer because of “industrial evolution.” Forgive me if I lack faith. At the end of the day though, I agree with him: TypeScript likely has a bright future. I should probably move forward with it. But Chris’ words of caution have not fallen on deaf ears. I get the point: adopt new technologies cautiously.

What do you think? I’m sure you’ve noticed how fast technologies are changing. I mean, who was talking about React, five years ago? Now you can’t get job unless you know it… Are you a slow-adopter, or think it’s vital that developers stay up-to-date with the latest and greatest? Drop a line.

Where have I been?

Doctors playing my game.  

It has been a while since my last post. Some of you may be wondering what’s up with that. Well I’ll tell you: I’ve been working - working hard. My company recently had a big event, and it was all-hands-on-deck. We were at it full-throttle, for a few months. I managed to squeak out a few articles, in the beginning, but then the workload became too much. One of my applications was in the show. I had to focus. Everything went very well, though! Doctors from all over the world played my game; I even saw them taking pictures beside the screen. I’m still elated!

Since then, unit testing has consumed much of my time. I currently have a few projects on my plate, and they all need tests. I know, I know… I should have written them first. Well, I’m new to this, and deadlines are real. Writing had to take a backseat, while I learned the Jasmine framework, and how to properly implement consistent, fast, accurate tests. That’s definitely more than a month-long process; I still have plenty to learn, but I’m making progress. And I like the results. The first unit tests I ever wrote were on the backend (PHPUnit), and weren’t really good. I learned a lot, though, and much of it transfers to what I’m doing with Jasmine. I find the confidence from testing, and ability to skip the browser (I use Karma to run tests), are worth the extra effort. I plan to make this a permanent change in my workflow. Maybe I’ll elaborate further later, but for now, I just wanted to give you an update on what I’ve been doing.

I plan to continue writing; I find it helps me better understand development. Furthermore, I write for developers and dev teams. My hope is that these posts eventually lead to fruitful discussions that help me become a better developer. Lets see what happens...