The Cacophony of the 2019 Tech Landscape

This is a guest post from Rishi Malik. Enjoy.

Hello New Developer!

Right now, it’s Q1 2019. And there’s a lot of advice you’ll find out here on the internet. Much of it is good, some of it is bad, but the important thing to note is that these are all points of view from people. From that person to be specific. This letter is no different, this is just my view on what matters. Take it or leave it. In fact, that’s the first point I want to make.

2019 tech is full of voices. Social media, popular blogs, and news sites amplify voices and feelings. This is an awesome thing, but remember that loud views aren’t necessarily right.

What I mean, is that you’ll find points of view on everything. Developers have always loved flame wars, and pointless battles (vi vs emacs, tabs vs spaces). Now it’s “Javascript developers aren’t real engineers”, or “If you can’t code a binary search, you’re a bad engineer.”

Find yourself in all these voices. It’s not easy, and it will take time. But work on what you value, and develop your skills to who you want to be. It’s ok if you want to work by yourself on speeding up a search by .01 milliseconds. It’s equally ok if you want to ship a single page app with a brilliant user experience. Listen to the voices when they help, and ignore them when they don’t.

To help find yourself, focus on finding customers that value what you do. Most of the time, these customers are the people in the company you’re working for. But if you want to do algorithms, find people who will value that work. If you want to work on networks, find companies who need that.

It sounds obvious, but it’s an easy thing to miss when you’re looking for a job, and when you’re evaluating comp, culture, benefits, and offices. It’s also really hard to gauge from the outside of a company.

On that note, remember that the 2019 tech industry isn’t how it will always be. Right now, the job market is stellar. I mean really stellar. In most big cities, you can find a job doing just about anything you want, most of the time within a few days.

This won’t always be the case. It wasn’t years ago, and everything comes in cycles. That’s the 2nd point. Be willing to do things you didn’t think you wanted to. I worked on embedded systems when I started my career. I got into web technology not because I cared about it, but because it helped me get a job in a city I wanted to live. Turned out to a prescient choice, and opened up tons of opportunities I wouldn’t have had otherwise.

The tech choices come in cycles, but so does demand. I said before that the job market is stellar. But some of us old timers have been through the downturns. When you’re unemployed for 6 months because literally no one is hiring. When your choice is between a 50% pay cut, or a 100% pay cut. Be wise, be smart. It’s a great time to be in tech, but plan ahead for the times that are tough.

Finally, my last point is to remember that there is a world outside of tech. It’s hard when you’re in it to see that. When tech was smaller, and more insular, it was easier to remember that this is a job.

But now, tech is everywhere. Apps are everywhere. The internet is everywhere. More people are writing code, building companies, and figuring things out. But, tech is not the entirety of life. Get outside of the tech zone, and connect with people who aren’t in it. It will change how you think, and how you develop code. And it provides a much needed break from the echo chamber that is tech.

Good luck, and have fun!

Rishi

Rishi Malik is the founder of Backstop.it, a company focused on making cybersecurity easy for companies to implement.

Avoid The Impossible Goal of Being a Know It All

This is a guest blog post from Rick Manelius. Enjoy.

Dear new developer,

Can you name all 50 US states? How about their capitals? Every city in the US? Every town? Could you list the GPS coordinates of every coffee shop?

Of course, you can’t, wouldn’t, and don’t. It would be absurd to spend the time and effort to memorize such a vast amount of information that you can Google within seconds. Yet developers often fall into the trap of over preparing and learning a myriad of facts and syntax trivia for a new programming language or framework before diving in and getting their hands dirty.

A personal example: When I landed my first contract as a web developer, I recommended Drupal for the client’s project. However, I was deathly afraid of not being able to address any questions that might come up. To satisfy my “need to know it all” before I put forth an initial proposal, I purchased have a dozen ebooks and read the more popular ones cover to cover several times. Meanwhile, I was only dabbling in writing code by following the tutorials.  Unfortunately, this was about as effective as trying to learn a foreign language without a practice partner. The information was forgotten almost as soon as I learned it.

I contrast this with how quickly my experience and skills grew when I started to give myself the permission to play, to test, to tinker, and to interact with the community through IRC and the issue queue. It was there that I would run into a blocker and use those eBooks as a useful resource because I had a specific purpose in mind. Moreover, when I couldn’t find my answer there or with Google, I could lean on others that were actively learning, growing, and sharing along their career trajectory.

Years later, I discovered this humbling infographic titled Becoming a Web Developer in 2017. I love this because it highlights the absurdity in trying to learn everything about everything in the web dev ecosystem. While all sites eventually roll up to HTML, CSS, and JavaScript, the number of underlying technologies used to support them is visually overwhelming.

68747470733a2f2f692e696d6775722e636f6d2f4d576b654d31382e706e67
A select infographic from The Web Developer Roadmap 2017

Each of the boxes represents a different subject matter. Each of these subject matters has additional, hidden complexity. Also, within that, there might be subsystems that maybe only a few core maintainers of that specific project would understand. Each box may take a day or a week to learn the basics, but perhaps months to years to master.

Trying to do that for every topic becomes an overwhelming investment of time for increasingly diminishing returns. It’s equivalent to learning the GPS coordinates of every coffee shop in the US.

To make matters worse, this infographic only represents the hard skills necessary to produce and maintain the software and its supporting infrastructure. It says nothing about the soft skills of how to participate and grow a high-performance team, how to make solid architectural choices, how open source governance works, how to handle change and release management, how to apply different project management methodologies, etc.

Before I overwhelm you any further…

…there is hope.

You don’t need to know it all. In fact, some of the most successful developers I’ve come to know are skilled searchers and askers. They may not know the information, but they know where it could be. They know how to parse documentation to find the salient details they need to accomplish the task at hand. They have a network of colleagues in other specializations that they can lean on for help. They are confident in asking even basic questions (gasp) in public, because while it may seem obvious for many, there is always at least 1 other person who has the same question.

Let’s look at the medical profession for inspiration. While they all go to school for 6-12 years to gain a base level proficiency, they can then either stick to general practice or hone in on a dizzying array of specialties. When we get sick, we start by going to our primary care doctor. Their goal is to identify and solve the problem there, or narrow down the answer space and refer you to a specialist. Unfortunately, even the specialists don’t always know what the issue is. This is why people sometimes need 2nd or 3rd opinions.

The good news is that in software we don’t need to go to a school for a decade to get started with experimentation or specialization. We are one tutorial and terminal prompt away from trying a new language or checking out a new library and testing it in a local sandbox where little to no damage can be done. There is so much power in this! And it’s also where it can be overwhelming given the 28 million public code repositories on GitHub alone.

Adopt a Hive Mind Approach

We live in a golden age of sharing and collaboration. Developers from all around the world ask and answer questions on Stack Overflow. They write tutorials and howtos on their blogs or Medium. In any given city, there may be anywhere from 1 to 20 tech Meetups a week. There are podcasts, Reddit channels, newsletter aggregators, and active conversations on Twitter.

By asking, discussing, and sharing openly in one or more of these venues, you are adopting a hive mind approach. You are both able to contribute to and receive ideas, perspectives, and solutions. It’s hard to overstate the importance of this strategy and mindset. In my experience, it’s many times more valuable than reading the 3rd or 4th ebook on a given subject (although these are often a useful reference). Beyond just discovering technical solutions, interactions with other developers often result in friendships that can last well beyond the burning framework question you had when you first met them.

So my advice (take it or leave it) is to abandon the lone wolf, know-it-all approach to software development. Instead, learn to contribute to and draw from the collective skills, talents, and experience from our fantastic community that is literally all around you IF you are willing to connect with them.

Final point. I stayed isolated for years until I broke into the Drupal community. Once I did, my career rapidly transformed. I wrote about that here.

So get out there! And good luck!

– Rick

Rick Manelius is an MIT engineer turned web developer turned startup CXO (operations, product, and technology). You can connect and learn more on his personal blog and his LinkedIn profile.

Tips from a recent bootcamp graduate

This is a guest blog post from Jesse Ling. Enjoy.

Dear new developer,

Be comfortable with being uncomfortable. You’ll never know all the things. And that’s ok.

Ask questions – at the right time. There’s a fine line between reaching out for help too early and too late. Struggling is imperative to growth, but reaching out for answers too soon significantly hinders it. You’ll better understand where that line lives over time.

“Stand on the shoulders of giants.” More than likely, your problem has already been solved. Don’t be afraid of trying other’s solutions if it makes sense for your implementation. But do take the time to fully understand why and how it works.

Be persistent. Programming is difficult and often times frustrating. Don’t give up. The feeling of figuring things out after a struggle is amazing.

Network. Talk to devs at, below, and above your skill level. Opportunities can present themselves in mysterious ways. Utilize your network to not only help yourself, but more importantly to help others.

Sincerely,

Jesse Ling

Jesse Ling is a motivated and relentless problem solver, and a recent Turing School graduate seeking web development opportunities.

Outcomes over output

This is a guest blog post from Mark Sawers. Enjoy.

Dear new developer,

As a software engineer, it’s easy to take our eye off the ball. The ball we really want to pay attention to isn’t the stuff we focused on in college. The ball is improving business/organizational outcomes. There isn’t a course of study or advanced degree on this, because it’s bespoke and custom to every organization.

You are on a team in your organization’s grand game to help the underserved, make money for shareholders, find some cure, save the planet or whatever its mission. A software-intensive system improves information access, automates task, entertains, etc. You pair with your business discipline in conceiving, building, testing and operating systems that advance the game.

Your real value to your organization is in improving outcomes. Not directly in how well you wield language X, tool Y, process Z. Not in how many features you add in a sprint, how many bugs you fix in one day, how much code you reviewed yesterday, how many answers you posted in slack, how many documents you wrote last month, and so on. Those are just means to an end.

Yes we need to constantly develop and hone technical skills (analysis, modeling, diagramming, programming, unit testing and others) and tool knowledge (languages, frameworks, utilities, operating systems, and more), but don’t mistake this for the end-game. Yes we should measure productivity; we do care about efficiency and throughput. But more product features, the latest tech, continuous deployment, two-factor authentication, and so on are not the goal. More is usually less, in my experience as a user. Isn’t that yours as well?

The goal is not output; the goal is outcome. The outcome is more revenue, more profit, more users, more product availability, happier users … right?

So, wait, isn’t that someone else’s job? What do you know about forecasting and measuring profit, anticipating user needs? Isn’t that on the product owner? The product manager? Marketing? And isn’t uptime the operations team’s responsibility? And finding problems the QA team’s responsibility?

You are on a multi-disciplinary team. You have at least one vital role to play on this team. Engineering is your trained discipline, and likely you focused purely on development. The smaller the company/business unit, the more hats you will wear. Yes your main contribution is technical, but in service of the bottom line. But don’t stay in your lane! Different perspectives are essential to this game. Your product owner doesn’t have a patent on designing end user features. And she may not be thinking about measuring success. Help her define the metrics and build those collection and reporting tools into the product. After you deploy a new feature, assess its success; don’t immediately move on to the next feature.

OK, so do I eat my own dog food? I try. The tech side requires lots of cognitive space, and so outcomes are easily short-shafted. Also, I have found this holistic perspective difficult to practice in large organizations. There is lots of specialization. It fragments responsibility. Incentives are set along discipline silos. My suggestion is to play your organization’s games (don’t leave that bonus on the table!) but bring your enlightened perspective as best you can.

Good luck,
Mark

Mark Sawers has been practicing software engineering for almost 25 years, as a developer, architect and manager. You can find his blog at http://sawers.com/blog and his LinkedIn profile at https://linkedin.com/in/marksawers .

You can do this.

This is a guest blog post from Kyle Coberly. Enjoy.

Dear new developer,

You can do this. There’s a lifetime of stuff to learn and it will seem intimidating, but if you keep doing it, you’ll get better. Teenagers, career changers, and retirees all have done this, and they weren’t any smarter or more naturally talented than you. You’re in the right place.

Make stuff. It’s easy to get lost in a bunch of theory, especially when it’s dressed up as “the fundamentals.” You can learn theory any time. Seriously. Learn what you need to learn to make something that interests you, and you’ll learn a lot and get enough fuel to get to the next station.

Participate in the software community. Go to meetups, join a community forum or chat group, go to conferences. There’s a lot of people exactly where you are, and a lot of people who were there not so long ago and want to help you get better.

Sincerely,

Kyle Coberly

Kyle Coberly is the executive director of the Develop Denver conference, co-host of the Sprint UX Podcast, and serves as the Technical Lead for Health Scholars. Previously, he was the Faculty Director for Galvanize’s Web Development Immersion program.

Write that down!

This is a guest blog post from John Obelenus. Enjoy.

Dear new developer,

Even when I was a kid in school I hardly wrote things down. That’s why we had textbooks after all! I was baffled by other students in college furiously transcribing every word that came out of the professor’s mouth. Now I have a career in the world of software where we track everything. Git holds all the code commits, email is never really deleted, and project management and issue tracking tools keep track of what we’re doing and have done. How could anything go missing?

I constantly looking for things and cannot find them. I get a bug report, look at the code and say to myself “That is obviously wrong, let’s fix it.” I look at the offending commit that introduced the bug (of course it was me). But what is not there? The reason for the change. So I look at the project management tool we use. And someone definitely asked for a change, but, I’m still not sure why. So I search through my email for the few days before I made the change, and…nothing. I still cannot really figure out why we all decided to make a change which introduced a bug.

Or, worse yet, someone asks for a change. All well and good. Then a month later, someone asks to change it back. So you shake your head and make the change. Then someone is confused why this is happening, and calls a meeting and invites you to help figure it out. What are you going to bring to this meeting? Did you write anything down? I never used to. Now I do.

Now I have a notepad next to my laptop. And I have a notebook on the shelf. I make better use of git messages and write down who asked for changes. When working on a feature, or a bug, and find something…“interesting” I make a Github wiki entry explaining it. I write a comment in the code base explaining it. There are two kinds of documentation — useful documentation, and redundant documentation.

No doubt many people have told you to comment your code. I hope many people have told you never to comment a loop with // loop over the array. That is not increasing clarity, its just duplicating what the code is doing. Adding noise, not signal. My contention is that comments are rarely useful for explaining “What this code does…” but rather, explains “Because of X, we are going to do…”.

Future you is going to be very happy if you start documenting the intent behind what you’re doing. Good code is easy to read. Bad code is capable of being understood with time. But code doesn’t tell you why you’re doing all this work in the first place. Maybe something has changed and you don’t even need this code anymore — deleting code is the most satisfying feeling. But you won’t know unless you know the intent, the purpose, of the code. And the rest of the folks you’re working with are going to be very happy as well.

If you write everything down (and make it public), they won’t need to tap you on the shoulder when you’re in “The Zone” to ask. When someone wants to set a meeting to understand why things are “The Way They Are” you already captured that information. You can send them the link and kill the meeting (Ok, maybe killing meetings is more satisfying than killing code).

We only have so much time in our life, and we already work long hours. Let’s make future us happier by writing things down, so we don’t have to figure it all out again. We figured it out once when we wrote the code. So capture the knowledge in that moment in time. And Write It Down!

Sincerely,

John Obelenus

(Previously published at Medium)

John Obelenus solves problems and saves time through software and crushing entropy

 

J

Always Be Journaling

This is a guest blog post from Brooke Kuhlmann. Enjoy.

Dear developer,

Of the many techniques you’ll pick up over the course of your career, one worth investing in early is journaling. Journaling might not seem like a worthy endeavor at first. Capturing important moments of your life on a daily basis might even seem like extra work on top of everything else you are juggling in your life but, in time, journaling will pay dividends if you stay disciplined and detailed. As you grow older, the details of earlier experiences will grow foggy in your mind. Being able to reconstitute past experiences in order to apply to them to present situations will help you make more informed decisions.

Additionally, journaling serves a dual purpose as it makes you a better writer. This is a wonderful skill to have which shouldn’t be underestimated. In addition to technical expertise, being able to express your thoughts succinctly, supported with documented details, is a sought after skill. Inadvertently exercising this part of your mind, on a regular basis, will allow you to keep this skill sharp.

Organization

How you organize your journal entries is up to you. Everyone is different and there is no right or wrong way to do this as long as it makes sense, is easy to add new entries, and can be searched through quickly. To start with, journal entries are meant to be chronological, so it does help to use a date/time structure. Example:

Format: <year>/<month>/<day>/<hour>/<minute>/<second>
Example: 2018/12/01/10/10/10

Use of categories (for high level organization) and tags (for associations across categories) can be helpful too. Useful categories to start with could include:

  • Work – Lessons learned from paid work. In addition to the benefits of helping you stay organized and not let important ideas slip through the cracks, this also serves as a way to measure the pulse on how you are feeling about the work you are doing and the progress being made. When you look back over time and see a rocky or downward curve, it might be time to move on to something new. On the other hand, the use of your journal might be motivational, can serve as a reminder to explore previous ideas in greater detail, and can even help solve current problems.
  • Side Projects – Lessons you want to capture related to open source software, hobbies, etc. that might be worth sharing in a public forum at some point but currently is raw material.
  • Personal – For private thoughts and ideas of use only to you. This might include your health, mood, personal reflections, relationships, etc.

As for tags, you might want to use a single tag or multiple tags in order break down journal entries beyond high level categories. Tags make it easier to search for entries faster when, for example, you have a Dotfiles project you’ve been working on and you have it tagged as dotfiles too. Using multiple tags helps connect related journal entries across categories which is another nice way to group related information.

It never hurts to have a few tools to ease this organization of your thoughts. Here are a some recommendations:

  • Bear – Supports macOS, iOS, watchOS. Has great sync capability between desktop and mobile, hybrid Markdown support, and tends to be a more free form in that you can organize and tag information however you see fit. It’s free to get started and $15/year to add pro and sync features.
  • Day One – Support macOS, iOS, and watchOS. Tends to be more specialized for journaling but isn’t always the easiest to manage. It’s free to get started but $35/year for pro features.
  • Notes – Native to macOS and iOS, provides a free solution for gettings started which sync capabilities.

Schedule

Choose a schedule, for writing journal entries that you are comfortable with. I would recommend at a minimum, to journal daily, even if briefly. It’s up to you to be disciplined about this as as only you will benefit. You can schedule this as a recurring action in your task manager or as a calendar event. Use whatever best fits your workflow and be diligent about it.

In addition to scheduling, you can capture important events as they occur such as thoughts while in a meeting or when working on complex technical issues. Yes, a journal can also be a helpful scratch pad for further reflective and refined thought later. If real-time journaling isn’t sufficient, try scheduling an end-of-day reminder to reflect on the day’s experiences.

Automation, as mentioned earlier, is key to being successful so figure out what works best for your mind and mode of operation. Here are some tools worth adding to your toolbox:

  • OmniFocus – Based on David Allen’s Getting Things Done book. It can cost over $100 when you buy the macOS and iOS versions but syncing is free. It’s a powerful tool and worth the investment.
  • Fantasical – If task managers are not for you, consider investing in a good calendar software and setup recurring events/reminders that way.
  • Reminders – Doesn’t have a lot of bells and whistles but will definitely help get you started until you outgrow it. Free for macOS and iOS.

Reviews

In order to learn from past mistakes, experiences, and build upon earlier lessons it is important to review and reflect and on your progress. A good rule of thumb is to conduct this kind of “self retrospective” weekly, monthly, and yearly. This’ll help keep where you have been and where you are headed in perspective. Plus, it’s nice to see how far you’ve come or gone off the tracks in case you need to pivot and course correct.

Personal Results

Over the years, maintaining a Pensieve so-to-speak has made me:

  • A stronger writer – As mentioned earlier, since I’ve been journing, I’ve found I’ve become a much stronger when writing Git commits, responding to group chat responses, creating pull requests, replying to emails, etc. I find my content is structured and well composed rather than short, terse, or staccato.
  • A stronger learner – When capturing and reflecting on the various experiences of your past life you can see connections that weren’t there before. It’s fascinating when I reflect on past work and realize I’ve forgotten a tool or technique that I didn’t fully understand at the time. Now I have much more knowledge and context for how to apply that to the current situation and thus have saved myself additional time.
  • A stronger mentor – When you accumulate a lot of experience and expertise, you can forget what was the source of your tacit knowledge. I’ve found being able to search for and share recorded knowledge so others may learn and grow in a similar manner helps make you a fount of information.

Closing Thoughts

Your future self will thank your past self for recording this history. Being able to understand the long tail of your work — and therefore your life — is valuable in making informed decisions on what actions you’ll take next. Mine this information often because your experiences are gold.

Sincerely,

Brooke

Brooke has been developing software for ~20 years with an emphasis in the Ruby and Elm languages. He lives and works from his home office in Boulder where he enjoys the many bikes paths and close access to ski slopes. When not working on open source software or hanging out with this novelist wife, he can be found speaking at conferences on the Git Rebase Workflow or attending the various local meetups: Boulder Ruby Group, Front Range Elm, or Denver Modern Web.