Flashover

Weekly blog posts about creative work in the tech industry

Page 2 of 7

Previous

Next

I Dread Sales

Jan 13, 2019

There is a high chance that you are currently trying to sell. Your job title might have the word "sales" in it. If you work in consulting, your employer might be expecting that you are able to identify your client's unarticulated problems and offer them the tools and resources to solve them (this is what selling is basically about). You might be selling your freelancer services or you might be selling yourself as a job applicant to future employers.

You might be even able to identify sales tasks in your work that other people don't traditionally consider as sales.

There is this idea that we are all in sales. We are all trying to persuade people to take action. We are all trying to connect and build trust for some mission.

You might agree with this idea. But you might not identify yourself as a person who is good at selling. You hear people tell their sales success stories and you wonder why you struggle with sales so much. Someone tells you that sales is easy but that's the exact opposite of what your personal experiences tell you.

I feel this way constantly. I personally believe that we are all in sales whether we like it or not. But I often also get discouraged. I think to myself that I'm not made for sales. There is some natural talent or a personal trait that successful sales people have and I lack.

But here's the thing. For the most of us, selling is not easy. Selling is hard and selling is scary. Don't feel discouraged if the idea of calling a client makes you sweat.

The story of Sara Blakely (founder of Spanx) is all I need to remind myself that the fear of selling doesn't mean I can't do sales--or have those moments of success in sales.

Before founding Spanx, Blakely was selling fax machines door-to-door. She had to deal with rejection constantly. And sometimes she just wasn't able to handle all the noes. She felt defeated. She would drive around a same block multiple times before she was able to convince herself to walk in through a client's door. On some occasions, she had enough courage to walk in through the door but when someone asked what her business was, she would instantly turn on her heels and walk away.

Blakely's story is not the story of a perfect sales person bursting with confidence. It's a story of a sales person who is human and who has to deal with human feelings. And most importantly it's a story of hope. After all, Blakely didn't quit sales. Instead, she built a billion dollar company on top of her sales skills.

Do you think sales people are born or made?

Remember Timing

Jan 6, 2019

When Laurie Voss (COO of npm, Inc.) goes to talk at coding bootcamps, people often ask him how did he get started in web development. Voss's answer is that he got started at the same time as web development. He was able to learn web development by having different web technologies accumulate around him.

Voss acknowledges that this strategy for learning doesn't really help a person starting a web development career in 2019. These days the world of web technologies is huge and it's complex. Even though the access to learning materials and the quality of developer tools have improved, it will take longer for beginner developers to comprehend the full capabilities of web now than it took 20 years ago.

You can look up to Voss as inspiration and you can learn from him. But you can't walk the same path as he did and expect to end up where he is now.

When HubSpot was founded in 2006, it was competing with 13 other marketing software products. In 2018, that same market consisted of over 6,000 products. HubSpot's CEO Brian Halligan knows this and says that the web will treat your startup differently than it treated HubSpot back in the day.

As a final piece of great non-advice, Hank Green (YouTube vlogger, entrepreneur, author, and co-creator of VidCon) says that the best way to get a large audience on YouTube is to start in 2007. That way you will have a somewhat established reputation when the masses arrive on the platform.

Voss, Halligan, and Green didn't get lucky. Things weren't easier for them. They still had to show up and do the work. They had to invest time on things and ideas that were unproven or contested.

We can continue to learn from the most influential people in our fields. But we also need to find people who are a little closer to where we are now.

We can continue to learn the fundamentals of the web and further improve our current skills. But we also need to open our eyes and observe what exactly is happening around us.

Why Do We Make New Year's Resolutions?

Dec 30, 2018

Tuesday will be the first day of 2019. We are all reflecting on the past year. Some of us are making New Year's resolutions. A lot of people will try to stop smoking or decrease their alcohol consumption. The gyms are about to get packed.

Why is this happening? Why is the start of a new year so important when it comes to setting goals and starting new habits?

Hengchen Dai, Katherine L. Milkman, and Jason Riis (The Fresh Start Effect: Temporal Landmarks Motivate Aspirational Behavior) suggest that our motivation for self-improvement peaks around the New Year because it opens a new mental accounting period, or a fresh start.

When a new mental accounting period opens, we feel a disconnect to our past imperfections. In addition to this, we experience a disruption to our daily decision making habits. Instead of focusing on time and effort as we normally do, we pay more attention to the end state of our actions. We are able to visualize the superiority of our future selves and direct our thinking towards high-level goals.

The start of a new month or week is another opportunity for people to experience a fresh start. You can actually see people pay more attention to their health around these times the same way you see them do during New Year. Individually, birthdays or other meaningful life events can also open new mental accounting periods.

Even though time progresses in a constant way, we don't perceive it as such. When we look at our own personal or communal history and future, we can identify temporal landmarks; dates that act as fresh starts.

This all might be fairly obvious. But think about how you can leverage this fresh start effect. Take advantage of the naturally arising temporal landmarks such as this New Year. Create your own fresh start moments by moving to a new apartment or getting a tattoo. Reframe people's thinking and associate change inside your team or organization to temporal landmarks.

A lot of New Year's resolutions will get broken. We all know this. But even though motivation does not equal the hard work that is required for any kind of personal change, you need motivation to initiate action and get things rolling.

New Year is an opportunity.

What to Learn in 2019

Dec 23, 2018

This post won't tell you which programming languages and frameworks you should learn in 2019. This post is about making a commitment to learning and embracing curiosity.

In terms of learning and myself, 2018 was a deep dive to Ruby and JavaScript. Those were the languages I programmed with at my day job and on the weekends and nights. As this year started to come to an end, my desire to do more exploring outside of Ruby and JavaScript and their ecosystems increased. I was ready to add more on my plate.

Unfortunately, my desires did not exactly manifest themselves in studying and practice. If I'm being truly honest with myself, I feel like I could have done a little more work and a little less day dreaming about all the possible technologies I could learn and experiment with.

There is no one reason why I ended up spinning my wheels. However, I am aware of some of the internal conflicts that contributed to this indecisiveness. A part of me is afraid that I won't be able to focus on the technologies that will make me relevant as a software developer in the future. A part of me is afraid that I'll miss an opportunity because I chose to learn the wrong programming language.

We all end up reading articles that list the most popular programming languages and frameworks. Even if we don't seek out those articles, they will pop up on our social media feeds and article suggestions. On those lists, there will be technologies that we haven't tried out or learned yet. We get anxious. Our fear of missing out increases.

It's these kind of feelings that make me want to brush up on my Python skills, laser focus myself to JavaScript, or start learning Java.

I'm not hating on any of these languages. It's just that for example in the case of Python, I'm afraid that the language is too similar to Ruby. While focusing on Python will increase the amount of opportunities I have on the job market, it won't present me a true challenge or elevate me dramatically as a programmer.

This week I have made a decision to focus my efforts to learn new technologies on things that truly interest and inspire me. I'm not going to care which programming languages have the highest salaries or the most secure career paths. I will block out a lot of opinions.

Here are the three new languages and frameworks I'm hoping to learn in 2019. If I get to study all of these technologies and build a small project with each one of them, I will be satisfied.

  • Go: Go has a philosophy of minimalism behind it: the language's core has limited features to make it easier for newcomers to start writing and reading Go as soon as possible. I'm excited about this philosophy. Go's emphasis on concurrency is an extra bonus.
  • Elm: Elm's value proposition of highly performant UIs with no run time exceptions is compelling. In addition to this, I'm simply intrigued by the idea of building a modern UI with something else than JavaScript.
  • Flutter: I cannot lie; the biggest reason why Flutter has caught my interest is because it's so new and shiny (beta version of Flutter was released this February and version 1.0 came out in December). In 2019, I'm hoping to learn more about mobile development. Flutter seems like the perfect accomplice for this objective.

In addition to Go, Elm, and Flutter, I will continue to perfect my skills with Ruby and JavaScript. I will strive to improve on my abilities that currently generate value for my clients and teams. But I will also make time for genuine curiosity. Not because it will add to my yearly earnings. But because it's inspiring and it's fun.

This list is not your list. You should make your own. You might be drawn to different things and there is nothing wrong with that. There is also nothing wrong with focusing on technology-specific skills that are sought after in the job market; you might be looking for your first developer job or you might be looking for an opportunity to switch companies.

The main thing is stop spinning those wheels and make a commitment.

Happy holidays y'all!

Working Software over Comprehensive Documentation

Dec 16, 2018

Two months ago I got interested in the four agile software development values. I have never disagreed with the values but I also haven't really reflected about them on a deeper level. Previously I have written about the first value of "Individuals and interactions over processes and tools." This week I'm discussing the second value, "Working software over comprehensive documentation."

We probably all hate writing documentation. But instead of bad-mouthing docs, I want to start out by pointing out the value of good documentation. The second agile value doesn't state that comprehensive documentation is useless. It just states that working software has more significance than comprehensive documentation.

Comprehensive documentation has two key benefits to any organization or team: it externalizes knowledge and it builds up shared understanding. When we externalize knowledge we take the internal knowledge of individuals and articulate it to a shareable form. When we build shared understanding we build shared vocabulary and common ground.

While documentation is a great tool for knowledge sharing, it's also time-consuming to produce and difficult to make it digestible. In addition to this, maintaining massive amounts of documentation is an enormous task. Especially when you are adding new features to your software every week.

None of us want software teams that spend the majority of their time writing and maintaining documentation. We want teams that iterate and move forward.

So what do you do? First, don't write documentation for its own sake. Write down the stuff that really matters and that is easy to communicate as written docs. Second, you can externalize knowledge and build shared understanding through other means than documentation. You can supplement your minimum viable documentation with different practices. Let me go through some examples of this.

When I'm onboarded to an existing project and try to understand how different features work, I start out by reading the integration tests for those features (integration tests combine different units of the software and go through different use cases). Sometimes the purpose of documentation is to describe how a system works. Easy-to-read tests achieve this same goal. Also, unlike documentation, tests stay up-to-date even when the development team's velocity is high (developers are forced to keep their tests passing and therefore rewrite tests when necessary).

Comprehensive documentation for a development team can also help them to reduce ambiguity and increase the consistency of their work. However, if you are able to adopt known systems and ways of working for your team, you don't necessarily have to write your own documentation--the documentation is written for you! For example, if you and your team decides to adopt git flow or trunk-based development as your development style, you can take advantage of the existing and public documentation for those systems.

The last example deals with the issue of knowledge sharing between technical and non-technical people inside a software project. Documentation can make it easier for people with different backgrounds and skill sets to find a shared vocabulary. But so can face-to-face discussions around artifacts such as post-its, wireframes, and demos. In fact, these discussions can achieve something truly important that documentation can't: they can uncover misconceptions and conflicts. Sure, interactions don't scale the same way as documentation scales, and discussions around misconceptions and conflicts can be uncomfortable. However, if you aren't right now dealing with a scalability problem, you can keep knowledge sharing as a more personal, non-scaling activity.

Final notes

Documentation by itself has no meaning. The meaning comes from the valuable knowledge that gets distributed to different people. Is your team documenting things? If not, what are the ways you are building shared understanding or keeping your work consistent?

Page 2 of 7

Previous

Next