In an instant, everything fell into place: I got a job offer at JWPlayer, I accepted that offer, I quit my job at DataOnline, I got a 1-bedroom in Kips Bay, and I moved out from my Grandmother's duplex in Bayonne. I started May 1st and so far, so good. I work longer hours but I love the job and I work on a great team. The company is doing great. Living in Manhattan is exhausting but fun and worth it. Life's good.

Since moving and starting this new job I've been focusing on growing my (non-programming) hobbies and (non-programming) personal skills. I program enough during the day to scratch that itch - which usually leaves me wanting to do something else. I've picked up biking and homebrewing and have been working on myself. I stopped going to meetups. Maybe I burned out. So it goes. But as my life sets into something resembling balance I'm finding that I want to have side projects again, speak at meetups again. I'm typing this at BrooklynJS. I'm working on a fun side project. I can't do this every day but every now and then is enough.

This past Wednesday (March 16th), I gave my first meetup talk ever at the nodejs NYC meetup - and it went pretty damn well. It was a pleasant surprise since I'm rather used to the typical first-try blunder. There were about 30-40 people in attendance, and photo evidence of my time on stage shows not a single person on their smartphone. Victory indeed.

My topic was on using React higher-order components to make D3 components responsive without sacrificing testability or reusability. Not the most riveting topic, but suprisingly few people know about HOCs and I was glad to educate. It also gave me a chance to soapbox about the virtues of functional programming (which will be big soon, I swear).

I think that a large part of my success can be credited to the dozens of talks I've sat in on before making my own. I noticted that the most successful ones hardly talk about code - they're mostly about ideas and the personal connection to their topic. Talking to a friend afterwards, he put it nicely: "Your first job is to entertain, and the second is to educate. If you've done the first you've already won". If your audience is asleep, what have they learned?

Check out the demo and slides 👀

Have you ever tried explaining something you use or know well, only to be find yourself stuttering, stumbling, and floundering about? The words are right on the tip of your tongue - stuck firmly, and unable to shake loose. What gives? As a frequent beginner I've know this feeling many times before. Since realizing this I've made a conscious effort to practice what I call "surfacing knowledge". Surfacing knowledge is the act of bringing succinct bits of the stuff you know, the stuff you know you know, right up to the top layers of your brain. Right where the knowledge is ready to be shared and explained effortlessly, a place where you shouldn't have to dig deep or look up-and-to-the-left to find them.

The key to surfacing knowledge is in the distillation of wide topics into grokkable bytes simple enough for a beginner to understand. It's taking the 0.0001" view and transforming it into the 1000". A sentence or two should be more than enough to get your idea across - any more, and you risk glazed eyes. The funny thing is that software engineering principles provide a pretty good guide to sufarcing knowledge. Composing small bytes together into larger ideas forms the basis of explaining complex topics without loosing your audience.

It's worthwhile to surface knowledge periodically, but even more so to practice it consistently and almost subconsciously. Whenever I learn something new I always imagine having to explain it to someone who knows absolutely nothing. It helps me solidifiy my own understanding and share it when I need to. When I'm bored and idle I sometimes reflect on what I've been learning and surface it manually. Blog posts, open-source projects, and meetups are also great for this. Practice it often enough and eventually you'll be surfacing on autopilot. ✈️

Well I finally did it. I made a new blog without any frameworks or javascript. And it was fun. It's a stark contrast to my first blog ever which was built on the MEAN stack, had a 100 line grunt file, and way too many npm packages. That was a mistake, but in my defense it was primarily a learning exercies. It feels good to finally unplug it though. As much as I enjoy playing with the lastest frameworks (especially React), I found it refreshing to make things with plain old vanilla HTML/CSS. It was also rewarding to study the arcane and long-forgotten art of static web development. There's a lot of framework-agnostic knowledge within which will make you a better developer. As a bonus, I get to show off my rad photography skills.

Programming is also hard. Style is hard. Programming style? Doubly so. What's easy is to ignore style altogether and Move Fast™. But style is one of the most important aspects of writing good code - and it can make you go faster.

Simply put, style is the way code is presented. Indenting, whitespace, variable naming, bracketing, capitalization, and too much to worry about fall under this category. But the simple placement of characters is an oversimplification. A better definition is that style is the intent behind the way code is presented. Style is used to display code in such a way that it's readable, maintainable, and in some cases, more performant.

Luckily for you (and me), style is easily stolen. In fact, it's even encouraged! The linter is an invaluable tool to introduce and maintain style based on what a community of developers feel is correct. Linters vary in their degree of opinion and extremes at which they force their style upon you, and are even available for uncool languges like C#. Good linters can point out silly mistakes or help optimize code - ESLint will point out when you should make use of const (or when you can't), and reminds you when you've accidentally for ined an object. Some linters like ReSharper will even refactor code for you across entire solutions. For Javascript, I use ESLint with Airbnb's styleguide and an additional guide made by a friend of mine. I used to use JSHint, but I recently switched because I wanted more style. For C#, ReSharper is bar none the best.

So how does style make you move fast? At first, it probably doesn't. Switching from JSHint to ESLint introduced 50+ errors across one of my smaller projects (and you shouldn't leave red squiggles alone). But adopting a good style gives your code consistency. Consistency gives you (or anyone reading your code) the ability to infer properties and behavior without having to refer back to initial declaration or scan line by line. Essentially, it gives you a mental code cache. With consistent names, you don't have to peck around for where the variable is actually declared to learn its access modifier. No more scrolling up and down to figure out what a module exports with consistent declaration location. When indentation is consistent, it's much easier to see what object another is encapsulated in. Even seemingly trivial things like whitespace before a bracket makes code more legible. Since programming 90% reading code (and 10% writing), having consistent code makes 90% of your job easier. So if you don't have style - get some 💈.

Last week was my first visit to the ManhattanJS meetup. And it was awesome. I've been to the AngularJS NYC meetup before but had a mixed experience. In a word, it was sterile - carefully prepared snacks, bouncers at the door, and people standing around awkwardly with hands in pocket. Everyone seemed to know everyone else (but me). The talk was interesting, but I left early.

But ManhattanJS was awesome. Beer, pizza, and a nice communal layout which made it easy to jump into different groups. Everyone was talking. There was music playing. It was loud. I got into discussions about how awesome Ember, microservice fetishes, and developer life in NYC. After the food, we shuffled over to the adjacent room for the main show - battledecks, followed by a tech talk and a 'passion' talk. For the unaware, battledecks is a game played by giving a presentation about a random set of powerpoint slides in front of an audience. I didn't participate but after a few beers I was wishing I had.

The next talk was about hypercard (Apple's 1998 edition of web technology), which humorously mocked the webdev trends with retro tech fads. Soon after was the tech talk. The topic was Mobiledoc, a new way of writing platform-agnostic markup with a bunch of cool features. And then came the 'passion talk'. Each event the organizers choose from a pool of members willing to give a talk about any topic they're passionate about. This event's talk was about YAF - young adult fiction. Animorphs, specifically, and how reading them helped her navigate emotional stress. And how Ellimist, who split into several pieces (each with a different function) when tricked into a black hole, was able to defeat Crayak with his newfound modular nature. Strength over intergalactic beasts - another great benefit of using microservices! Overall, ManhattanJS was a great experience. Next adventure - BrooklynJS!

• 10:00 - Arrival! Really excited to be here (again). The venue this year is much more segmented but it's quite nice. Still no Windows Phone app!
• 10:30 - Grabbed a free cold brew and headed upstairs to sit in on the Edge segments, which are more tailored for developers. Great talk by Namely CTO about hiring.I'm pretty hopped up on caffeine. Going to have a quick chat with her after the talk.
• 11:00 - Jet CTO is up, talking about microservices. They use a similar architecture to ours - microservices using a message bus/broker to communicate. Going to ask if they daisy chain services or are strict about using their bus for everything. Interesting point - they don't really do code reviews. Shoutout to YAGNI. F# as their main language is pretty sweet, definitely interested in that. No time for my question!
• 11:40 - Dropbox Product Designer is up. Only been working there 20 days! A lot of focus on product design.
• 11:40 - Had a quick chat with Jet CTO. Got a lot of good ideas about how to improve our microservice architecture. They try to be really strict about using their service bus and not doing one-to-one communication. Only do it if it's absolutely necessary. They also have multiple message brokers, which is a great idea. Something we kicked about internally but it'll be great to bring some authortative knowledge to the team. I'll have to look into Azure service buses also. He previously held a C# developer position at CitiGroup and covered a lot of the same ground we are! When I described our message broker he said his was almost identical - I was glad to hear that they made a successful system with the WCF netmsmq bindings. I think he liked my system for automatically generating WCF bindings without config files, since that was a large issue for them. I also asked him about their abandoment of code reviews. They used to have them, dropped them while getting their team on track (moving quickly?), but are bringing them back soon. We're definitely on the right track at DataOnline.
• 12:00 - Market yourself to your dream employer. I'm hungry but really want to listen in on this. Showcase yourself online - check (but does anyone actually read this?). Looks like I need to get my LinkedIn in order. Interesting point for learning about a company - read their code. He mentioned Medium, which I've been seeing a lot of on HN. I'll have to look into it. He keeps emphasizing the importance of a personal site. Understand what your dream company wants (100000 years of experience, probably).
• 13:00 - The floor begins!
• 15:20 - Quick break from the madness. Lots of good stuff so far and the layout is better so less crowding. This grapefruit beer is pretty good.
• 17:00 - Heading over to the front desk for my volunteer shift. Free tshirt! Takes a while for me to find a size medium. Trying to look busy while somebody tells me what to do. Looks like I'll be peeling vinyl stickers for a while.
• 19:00 - I'm free to go, and more than ready to sleep. The guy running the Batch booth gave us some free soap for our help. Smells delicious.