Category: PSA

Happy Year 5 of the Birth of The New Stack

This is the 2nd post in a series of posts on OSCON 2019, the first is “OSCON: What it is.“.

Happy 5th Birthday to The New Stack

I tend to write a lot of articles, documentation, and all sorts of various things. It’s one of the many things I enjoy doing. A while back my friend Alex approached me and presented this new idea for a tech publication he was starting. He mentioned he’d love for me to put a few articles in if I were interested. I was, and over the next several months as the company got rolling I added a few articles to the mix!

In those early days Alex started with all sorts of ideas about things to add to the medium beyond just articles. Over these last 5 years he’s worked diligently with a team of great writers, coders, and others to make those ideas happen! Here are a few of my favorite sections of The New Stack.

Podcasts – Of course there had to be a podcast the The New Stack right! Just recently there’s been some whiz bang awesome episodes. Check these out for a wide range of interesting tech topics.

Again, happy birthday to all at the The New Stack, hope OSCON was most excellent and awesome for y’all. Cheers!

 

It’s Official, ML4ALL 2019, Machine Learning Conference 4 All v2!

It’s official, we’ve got dates and tickets are open for ML4ALL 2019! Our CFP will be open in a number of hours, not days, and I’ll do another update the second that we have that live.

What is ML4ALL?

ML4ALL stands for “Machine Learning for All“. Last year I enjoyed working with Alena Hall, Troy Howard, Glenn Block, Byron Gerlach, and Ben Acker on getting a great conference put together, and I’m looking forward to rounding up a team and doing a great job putting together another great conference for the community again this year!

Last year @lenadroid put together this great video of the event and some short interviews with speakers and attendees. It’s a solid watch, take a few minutes and check it out for a good idea of what the conference will be like.

Want to Attend? Help!

Tickets are on sale, but there’s a lot of other ways to get involved now. First, the super easy way to keep track of updates is to follow the Twitter account: @ml4all. The second way is a little bit more involved, but can be a much higher return on investment for you, by joining the ML4ALL Slack Group! There we discuss conference updates, talk about machine learning, introduce ourselves, and a range of other discussions.

If you work for a company in the machine learning domain, plying the wave of artificial intelligence and related business, you may want to get involved by sponsoring the conference. We’ve got a prospectus we can send you for the varying levels, just send an email to ml4allconf@gmail.com with the subject “Plz Prospectus”. We’ll send you the prospectus and we can start a conversation on which level works best for your company!

The TLDR;

ML4ALL is a conference that will cover from beginner to advanced machine learning presentations, conversations, and community discussions. It’s a top conference choice to put on your schedule for April 28-30th, pick up tickets for, and submit a proposal to the CFP!

 

DevRel Data: Presentation & Deductions

Before diving into conclusions, let’s take a look at some answers to questions asked. This is a slice of answers, with totals for the charts and such. After a few months of answers I’ll have another follow up to see how things may or may not change.

Do you like video material?

chart

What specifically do you, or would you like to watch in video? Screencasts, short videos, conversational, or some other type of videos?

  • Screencasts/tutorials
  • I love both screencasts going through big topics and short videos that cover smaller tips and gotchas.
  • Videos with a specific outcome as the goal, whether achieved or not. Showing the process of something.. like hey, here’s how you building out a Postgres cluster using streaming replication and repmgr and pgpool… Kind of thing.
  • Bite sized content, maybe 2 minutes, to teach me one thing.
  • Editing. No jokes, no “hey what’s up guys” with 60 second intros. Discuss the problem, then solve it.
  • Demos, learning a new way of doing something
  • Doesn’t matter short or long, but has to be deeply technical with code examples that I can actually apply
  • I watch videos mostly for fun.
  • Screencast
  • Short videos of say 5-10 minutes each covering different concept of the subject matter
  • (videos work best in a classroom setting where time/attention is precommitted, or as part of a tutorial)
  • conversational
  • Short videos.
  • If it’s too long, it ends up on my todo list forever (not good). So shorter is better. And something that benefits from visuals, rather than something that could just be written.
  • I also watch LinkedIn Learning when just starting a new tech. to get a general overview and pick up a tip or tow, then I read books and the Internet from there.
  • short videos

What kind of written material do you like?

chart2

Do you like other material mixed in that details the reason for the tech, the story, or such?

chart3

Is there anything that comes to mind, that you’d like to have me or the team I’m working with (@ DataStax) put together that you’d find useful, entertaining, or related.

  • Place priorities on designing materials for more depth (i.e., more linked material) as well as less attention-nuisance. That’s no criticism of your work, merely the gestalt of where we work — so less noise is a better way to stand out and make materials useful.
  • Maybe focus more on written material – code & architecture material (books, articles) rather than videos and twitch. It is much easier to consume and is easily googlable. Also I’d suggest making blog posts target a specific common issue or question – sometimes I see posts that I don’t really care about or the problem is so narrow that I don’t want to read about it. I’d read about building resilient and highly available architectures in various configurations.
  • Database reliability, scalability, migrations and such stuff is interesting.
  • Anything to do with machine learning.
  • Data model examples, starting up a Cassandra node, configuring YAML, etc

Deductions

I’m going to go backwards through the questions and discuss what I’ve deducted, and in some ways what has surprised me among the answers!

First there’s the “Is there anything that comes to mind, that you’d like to have me or the team I’m working with (@ DataStax) put together that you’d find useful, entertaining, or related.” request and questions.

The answers here didn’t surprise me much at all. Within DevRel from Microsoft to DataStax to Google to many other organizations we have this ongoing battle between “write a whole book on it” or “make it 2 minutes short”. It’s wildly difficult to determine what format, what timing, and what structure material needs to be in for it to be most useful to people. So when I saw the answer that reads, “Place priorities on designing materials for more depth (i.e., more linked material) as well as less attention-nuisance.” I immediately thought, “yeah, for real, but ugh…” it’s difficult. However, I’m working on more thorough material, some of it will be paywalled via LinkedIn Learning or Pluralsight and other material may be available by book in the coming months. But there will be other material that will indeed be long form how to material on how to really put things together – from scratch and from the basis of “we have X thing and need to hack it so we can add a feature”.

The next answer I got in this section that I completely agree with is increasing the focus on written material. I’m making tons of video, and I’ve got that down to the point where it’s actually easier and faster to do most of it then it is to write things down. However I realized, especially from my own point of view, that written material actually ends up being vastly more useful than video material. That’s also why, even with the video material, when I’m covering specifics I aim to provide a linkable timeline and a blog entry with the code and other changes shown in the video. Thanks for reinforcing these efforts and giving me that indirect encouragement to make this process and the results even better. More written material is on its way!

As for the database reliability, scalability, migrations, machine learning, data modeling, Cassandra node starting, and all that it’s in the queue and I’m getting to it as fast as I possibly can.

Next question I asked is, “Do you like other material mixed in that details the reason for the tech, the story, or such?”

It appears, albeit not a huge contingent of people, some people are curious about biking, train coding, and making good grub! Hey, that’s groovy cuz I’ve got a show coming out which is basically the behind the scenes videos about all those topics that make the coding and technology hacking possible!

The one outlier in this set however is clearly the request for “Ways to simplify life to dig through those algorithms faster, easier, better?” which I didn’t suspect would be any different then the other answers for this questions. Which left me surprised and ill-prepared on what to do about fulfilling what is clearly a demand. I’ll have to up level my blog posts around algorithms. I did do a couple a long while ago now in “Algorithms 101: Big Sums” which I completed in Go and another I wrote up “Algorithms 101: Roads & Town Centers” which I have 90% of the answer complete but I’ve never finished the blog entry! I guess it’s time to get the algorithm train coupled up and ready to depart!

Then the question, “What kind of written material do you like?”

Two options lead by a healthy margin for this question: Demos w/ Write Up and Blog Articles. With this coupled up to the first question it’s clear that written material via blog and demoes via blog should and ought to be top priority. They are, however they’re a whole helluva lot of work, so I only get them produced but so fast. Got some gems coming on Go, Bash, Cassandra, and a few other demo, tech, and historical information.

Next up was single page cheat sheets and documentation, followed closely by books. I kind of expected documentation and books, but wow that single page cheat sheets option is higher rated than I would have suspected and by proxy I’ve immediately added that to my produce this type of material list! I put it in as a very secondary thought but it’s going to get into that increased focus queue.

The last one with some semblance of demand is pamphlet size short form. This one almost seems like a fluke, but I’ll ponder putting together some of these. I know O’Reilly has their short novelette size books which cover a particular topic. They hand these out for free at conferences and seem pretty solid. Maybe I’ll work one of those into the queue? Maybe.

The other three options scraped by with 1%, so somebody was choosing them. So the vi mug isn’t a priority nor the short explainer videos. Which seems in contention with video content demands around shorter content. I guess, explainer videos just doesn’t sound useful!

The next question I just put together a top three of the results, “What specifically do you, or would you like to watch in video? Screencasts, short videos, conversational, or some other type of videos?”

  1. Make screen casts.
  2. Make screen casts generally short.
  3. Make screen cases that are short and on a specific and deep dive into a topic.

This seems kind of in conflict with itself, but I’m going to aim for it and try to hone the skill further. So that I can produce screen casts, screen casts that are generally short, and make sure that these screen casts that are short are on a specific and deep dive into a topic. Whew, got it.

Finally, “do you like video material?”

chart

At this time, 53.8% of you have said yes. I had guessed it would be around 50%.

I had guessed no would be about 25%, and at 23.1% I wasn’t to far off.

The other respective mishmash of answers made for interesting depth to the questions that followed this question.

Article Summary & TLDR

Produce more topic specific, detailed material around screen casts and blog entries!

End of story.

For more on this information, why I asked, and what I do check out my article titled “Evangelism, Advocacy, and Activism in The Technology Industry” and for some of the big victories for big corporations check out “The Developer Advocates – Observations on Microsoft’s New Competence“.

Recruiters -> Software Developer Referrals, I Know Em’, Here’s How You Know Them

This is a public letter to all recruiters, human resources or other professionals that are in a *hiring department* that would like to garner referrals from me. I like to categorize my referrals into junior and senior software developers. This is not my interaction process with startups & early round companies, I know you and you know me, things work differently, so if you’re in a startup and looking for people this doesn’t apply to you. This is a letter to help guide how I can help all parties involved in the best way possible.

NOTE: I’m not a recruiter, not intending to be, nor do I work for any recruitment agencies or groups. This is something I do because I enjoy being involved with the tech scene of Portland and have great sympathy for people looking to join good teams. I fought years to find good teams and have enjoyed working with these teams. Matter of fact, I’d say a good team is orders of magnitude more enjoyable to work with than the not good teams. In other words, I try to make things not suck for everybody involved!  😉

For junior developer referrals, I have a few basic requirements and information that I’d like to know if there is a specific job in mind. If you’d just like to talk, I’ll also put you in touch with a junior developer based on this criteria.

  1. For the junior developer the positions should be of reasonable commutes, especially in the current software development market. This means that the commute, one way, should not be anymore than 10-15 minutes either by biking, walking or taking transit. If they want to drive, that’s their concern, but I don’t want to condemn anyone to ever being stuck with a forced auto-dependent commute.
  2. Is there opportunity that the junior dev will be working with other senior developers who will pair code, do code review and otherwise support the individual in a positive and enthusiastic way?
  3. Is the company active in the local community and supportive of new employees and existing employees being involved? Will the encourage and allow the junior developer to get involved and possibly attend workshops, courses, meetups and even conferences that may be during business hours (but likely most are not)?

For senior software developers this gets to be even more particular, especially in Seattle, Portland, San Francisco, New York or Vancouver BC. If I’m going to refer anybody the following items are a baseline.

  1. Does the job offer remote work or some remote work days? How does the team currently communicate with remote employees and what is the split of remote employees vs. in office employees?
  2. Not just is there opportunity to, but is there active pairing, continuous integration or delivery setup and being used?
  3. What is the current management paradigm around architecture decisions, user experience (UX) and other items that are often peripheral to the software development that occurs?

If these questions can be answered in the affirmative then I have some referrals for you. Even if they aren’t, these questions and this information should become standard on any job description, in MANY ways more so than the technology list of skills that are all to common. This last part is something to note for people hiring, not just recruiters.

I’ve also talked more about this far in the past (in tech years). I’ve spent many solid years hiring, firing and generally building teams of people. The following has inadvertently become kind of a series about suggestions to fix the job posts, and where and what the baseline is for building a A-game Team. Much of these suggestions hold true still today.

9 Ways To Survive The Shit Storm of Developer Evangelism

I started to write a blog entry a few months ago about my time doing developer evangelism. First in practice, along with product management and team leadership and then as a full time developer evangelist with Basho. Then I felt many different things, nothing which translated into a very useful blog entry. Well past any motivation to write up where and what I was doing at the time and why I decided it wasn’t something I wanted to keep pursuing, I ran into this blog entry titled “Developer Evangelism The Whole Story“. At that point I thought, “alright, I’m going to add my two cents after all”.

For one of the same reasons Keith Casey wrote his entry. People have asked me numerous times about becoming an evangelist or advocate. Be sure to read Casey’s write up, and here’s mine to throw more into that fire.

Positives:

  • You’ll be able to go to all sorts of cities and meet a whole bunch of different people.
  • You’ll be on display and actually able to do something to improve the industry. Not just technologically but to help resolve sexism, discrimination and other issues and treat people well.
  • Do right by people as an evangelist and you’re set for a plethora of possibilities when you finally get burned out.
  • You get to play with all sorts of tech.
  • You get to travel a lot, which makes you really start to respect your home base, wherever that may be.

Negatives:

  • You’re barely ever home, usually you’re on the road with familiarity often becoming the stink of a plane or the confused expression as the TSA security circus actually recognizes you and just starts ignoring you.
  • Even though you can help improve the industry, you’re ability to make a home, make a difference where you live is dramatically reduced to basically nothing. For most people, considering civic involvement in the United States, this probably doesn’t even matter. For some, it’s destructively depressing.
  • If you get mis-portrayed, say something dumb out of jest, or the media mis-quotes you it can be anywhere from annoying to career limiting or ending. If you make the mistake of pissing of someone that has a lot of pull then it could also be super destructive – even if that person is a total jack ass and everyone routinely knows it and admits to it.
  • You get to play with all sorts of tech, but you lose a lot of credibility because you don’t actually build anything real anymore. This is a huge problem, and I’d even suggest most evangelists go work on an actual dev team every other year or so. It doesn’t matter who you are, you will start to be perceived as a shill of some sort by a reasonable amount of people, even though they could be extremely wrong in that perception.
  • Your home base, you often don’t get to have a real home base. You are a vagabond. For a musical definition, listen to Metallica’s “Wherever I May Roam”.

Now if you still think this is a great gig for you. Thicken up that skin, get some callouses and get ready for a bad ass trip that’ll teach you about all sorts of human interactions and more. But be prepared and keep a solid look out for burn out and the degradation of any of the situations mentioned above. If you do you’ll likely do well. If you’re still interested, here’s a few things to get your kick start in developer evangelism:

  1. Get a social media presence, get it fast, and get a nick that you can use in almost all contexts. Don’t even pretend you can skip this step. The most successful evangelists have a huge social media presence and manage it. They manage it hard core, work it into a system, and learn efficient and positive ways to interact with that social media presence. Shut up, don’t even try to skip it, just go out there and manage it.
  2. Make sure to spend at least an hour a day doing something technical. Hacking on Docker, writing some scripts or heaven forbid writing some actual code. This is massively important because you’ll find yourself losing direction all the time from the task switching and not getting to do these little technical things that will help you keep your edge.
  3. Learn to speak. I don’t mean read a little book and think you know how to speak in front of a crowd. Likely, you really suck at it. I’m talking about practicing in the mirror, talk to yourself, record yourself and watch it and do all of these things without becoming nihilistic or pompous. Most of us tech speakers are so bad we’re lucky that the people in the industry are actually focused on the tech and not our stuttering horror of speaking abilities.
  4. Drop all fear to speak with people in positions of power. Remember, everybody is human, don’t get intimidated and don’t intimidate.
  5. Not that anybody in the software industry or tech industry or any industry needs told this but I’ll say it. Don’t overdo the drink. We’re all dangerously close all the time to being worthless drunkards. Some of us stay pretty functional on a drink or two, but that only lasts for a short time before you do indeed go downhill. Don’t deny yourself, you are NOT part of the one percent that can stay sharp and rot your brain. So keep the drink in check.
  6. Find a way, anyway, to stay physically healthy. If you don’t the travel can very likely kill you. I don’t mean like “I’m tired and want to go to bed” killed but more like “hmmm, Tory Joe McQuerty here sure did see like they were fine, too bad we’re putting them six feet under” killed. Oh, the “I’m tired and want to go to bed” will happen all the time too, just make sure you keep that as the only killed you get.
  7. Attain a huge amount of apathy for the extra overdose of everyone’s opinions about how everything sucks in the world. Many programmers are notoriously negative, especially if they work in the enterprise. It’s part of the daily war story if you get sucked in. Remember to stay focused on what’s important, your health and your loved ones, the job comes second. Anybody that tells you different, put them in that apathy category.
  8. Never feel like you have to explain yourself when you need to take some family time or personal time. Just say you need to and do it. Even if you’re pretty close to people on your team, they need to respect that and let you get some time in. This is extremely important.
  9. Don’t give to many fucks. Learn that at some point you gotta call it a day and turn in. Just drop it all and get a good night of sleep.

Summary: Think really hard about what you want when signing up for a dev evangelist or advocacy gig. It will wreck hell on your life, but it could be immensely rewarding too. But please, if you go into evangelism, practice at it and be prepared. I hate the idea of seeing more people burn themselves right out of the industry.

If you have anymore survival suggestions, please do comment!