You are what you buy?

Recently I have slipped into thinking I am defined by what I consume. For example, if I buy this REI shirt that will make me more of an outdoors person. Or if I found a clever deal for a bike rack on Craigslist, it will show the world how frugal I am and make me more of a biker. Or if I wait to buy a new TV, that shows that I have self-control and am not going beyond my financial means.

I also start zeroing in on what I will buy in the future. I spend a lot of time curating shopping lists, or finding the right reviews, and trying to decide whether I will buy a thing this month or next month based on my budget.

This is silly. My identity is not defined by what I buy, when I buy it, or whether I had good self discipline. I think I have been too much focused on how these exterior things define me.

Instead, I want to focus on things I create, adding value to the world instead of just consuming value. So for example, at work, I should be getting my projects done on time, and creating value by collaborating with my coworkers effectively. At home, I can create value by caring for others in a sacrificial way. I can create value by writing blog posts, or by being a good steward of things I already own. I want to have a vision for the future that is defined by how I will be faithful to God, not by how I will be faithful to my budget.

Learning in the midst of information overload

We live in a world where we are easily inundated by information. Our news feeds constantly update, providing an endlessly scrolling list of tidbits. There are always more Youtube videos, more podcasts, and more articles in our feed readers.

My own story roughly matches this. In the past I tried to cull my list of subscriptions: follow the right people on Twitter and unfollow the ones who tweeted too much. I tried to save time by only clicking on the interesting headlines. Ultimately I found that I still couldn’t keep up, and I was afraid of missing out on what I wasn’t clicking on.

The main mistake is “trying to keep up” in the first place—or having this passive, feed reading behavior be your only way of learning new things. Reading Twitter is a good way to keep up, but it shouldn’t be the only professional development that you do. Sure, it might help you discuss the latest ideas with your coworkers at lunch, but it’s also not going to go very deep for actually improving your professional skills.

Active Learning

Stop Passive Learning. Start Active Learning,” by Andrea Angela was the original impetus for me to write this blog post. The main point of the blog post is to stop endlessly consuming news feeds, because it leaves you constantly feeling behind. Then you have free time, and this allows you to choose a topic to learn, and then look for resources around that topic.

I like that Angela acknowledges that we won’t always have the mental capacity to do “active learning,” and that it is at those times that he turns back to his news feeds in a more passive approach.

Another blog, “Improve Your Self-Improvement” has a similar idea. Don’t just learn something and then set it aside. Share what you learned with others.

Ratio of producing to consuming

After I read about active learning I immediately remembered John Sonmez’s video about the 70-30 rule. This rule talks about the ratio of consuming to producing. Spend 70% of your time producing and 30% of your time consuming. Producing is making value for others, and consuming is just a passive activity where you are looking to be entertained or “informed” but you aren’t actually using that information.

When I think about the 70-30 rule I think of several contexts where I am producing and consuming.

At work, I probably do follow this ratio. In the work context, I would associate producing with tasks like coding, debugging, documentation, and giving demos. I would associate consuming with things like reading my email, checking out the work news feed, and reading the all-company announcements and stuff.

The other context is my after-work work, a term borrowed from “Improve your Self-Improvement” meaning professional development or personal development that is career-related that you do on your own time. In this context, I am striving to move more toward the 70-30 ratio. Some producing tasks include writing blog posts (yay, doing that right now), or taking notes, or coding on a side project. Some consuming tasks include watching Pluralsight, reading my RSS feeds, or other articles I come across on Twitter.

In conclusion, I want to be more proactive, and come up with my own ideas, rather than trying to react and digest others’ ideas all the time. I want to have my own opinions about what is important to keep up with in the tech industry, rather than just assuming that the newest thing is important to me.

Investing for retirement: some recommended books

Probably the biggest mistake you could make investing your money would be to listen to “advisers” who really are making a commission off your ignorance. Instead, you would do well to learn a little and then make your own choices. At the top I’ve put my favorite resource on this topic, a 16-page booklet by William Bernstein. There are also two suggested books.

“If You Can”

For those who don’t want to read an entire book about investing, I recommend Bernstein’s 16-page booklet entitled “If You Can: How Millennials Can Get Rich Slowly.” It is also available as a free PDF (linked from his website, halfway down on his “New Books” page).

The booklet gives a high-level overview, and also gives reading assignments for those who want to dive deeper (sorry, books are inescapable). It’s organized according to the 5 hurdles people who want to save for retirement on their own will face, paraphrased below:

  1. The temptation to spend instead of save.
  2. Lack of understanding of finance.
  3. Lack of understanding of the history of finance.
  4. Human shortcomings in long-term decision-making.
  5. The “monsters” of the financial industry who give “advice”

The Sound Mind Investing Handbook

The Sound Mind Investing Handbook: A Step-By-Step Guide To Managing Your Money From A Biblical Perspective, by Austin Pryor, is a good introduction to being a steward of money for God’s glory. The book is organized into sections according to different stages of personal financial management.

Section 1: Getting Debt-Free
Section 2: Saving for Future Needs
Section 3: Investing Your Surplus
Section 4: Diversifying for Safety
Section 5: Retirement countdown
Section 6: Investing That Glorifies God

Sections 1–5 discuss the how/why of personal finances from a practical point of view. Topics covered include asset allocation, timing the market (why not to attempt to time the market), the disciplines of investing, risk preference, and, how taxes will affect your investments.

Section 6 discusses the why of investing from a spiritual perspective. Pryor discusses his own story, how he got into the financial industry, and how he had a spiritual encounter and came to know Jesus Christ. Then he goes into what the Bible says about money, investing, and stewardship.

I think the strength of this book is its completeness. It serves as a good reference guide, due to both the variety of topics covered and the depth they are covered. There are some nice example calculations as well. On the other hand, at times the book can get a bit bogged down in its handbook style.

The Investor’s Manifesto

The Investor’s Manifesto: Preparing for Prosperity, Armageddon, and Everything in Between, by William Bernstein and Jonathan Clements, focuses on how the average person can manage their retirement savings successfully.

In the old days companies would give you a pension plan, and you would be set. But now the responsibility is on us to manage our 401(k)/IRA/what have you. Unfortunately successfully managing your retirement savings is a difficult task. It requires at least 4 abilities:

  • An interest in the process
  • An understanding of the math (probability and statistics)
  • An understanding of financial history
  • Emotional discipline to execute the planned strategy “come hell or high water”

The book is broken down into the following sections:

  • Chapters 1–3 give a theoretical basis and a brief financial history
  • Chapter 4 talks about “the greatest enemy facing investors”—look in the mirror, it’s you
  • Chapters 5–6 focus on executing your investing plan in the face of hurdles, like the “piranhas” of the financial industry

I enjoyed reading Bernstein’s book. He balanced out the investment details with some fun anecdotes and a bit of humor. All of the math stuff got swept aside into “Math Detail” sidebars.

Compared to Pryor’s book, Bernstein’s book spent less time on practical concerns like the cost of personal debt or how to budget, and spent more time on investment history and theory. Bernstein also covered a few more investment types, such as real estate investment trusts (REITs), which I had not personally been exposed to yet.

Being mediocre before being great

Do you have an ambition to be a top performer in your job? Do you have a hero who you want to be like when you grow up?

I have an ambition to be a top performer in my job. I have a picture in my mind of what success will look like, gleaned from reading and looking at leaders around me. Someday, I say to myself, I’ll be able to provide trusted advice on technical direction that improves the productivity of an entire department. Someday, I’ll be able to deliver a talks or write blog posts about my work that inspire and motivate others, and provide value to their careers. This is a vision of greatness.

However, before I can be great, I must be mediocre. The thing about picturing great success is it doesn’t tell me how to get there. I need to break down an ambitious and, to be honest, at times overwhelming, goal into manageable steps. I need to build the discipline to get stuff done. I need to be okay with failure and mistakes.

I’ve already taken some career steps:

  • I used my performance review as an opportunity to ask for a raise in writing. After listening to Kalzumeus Podcast Episode 12: Salary Negotiation with Josh Doody, I realize there are a few things I can do better next time, but it was a good first step.
  • I participated in my first story mapping/story authoring session. This is an agile practice for gathering user requirements in the form of a flow-chart-like diagram.
  • I started sending weekly updates to my boss. These detail my progress on company objectives and the general sprint work. See: Selling Yourself: How by John Sonmez.

By themselves, these steps don’t turn me into a software developer guru, but they are a step in that direction.

Another post on being senior

Last week I wrote about how senior developers take the initiative instead of waiting to be told what to do and how to do it.

Sarah Mei had a great series of tweets on the differences between junior developers, mid-level developers, and senior developers.

  • Junior developers need help figuring out how to do things. They don’t have the research skills to get things done on their own.
  • Mid-level devs have figured out the how and are starting to get the why, though they don’t communicate their ideas very well.
  • Senior devs long since figured out the how and the why. They have their own ideas and can get other people to go along with their ideas.
  • There’s a limit to how much impact one person writing code has. Senior-level impact is when you can change how other people write their code.

Tweets: 1, 2, 3, 4 (edited slightly since I don’t have a 140 character limit and I can add formatting)

I’m going to piggyback off what Sarah Mei wrote and add my own two cents.

First, the how. How is the basic mechanics of getting your job done. Say you need to fix a locale bug. The how is figuring out which source code is causing the behavior, and finding the file and line of code to modify. It’s also reading the docs to understand how locale is supposed to work.

Sometimes you get stuck. For example, you realize that in Electron, the renderer processes have access to navigator.language, but the main process does not. How will you make sure that the main process gets the correct locale?

I heard a rule of thumb that you shouldn’t let yourself be stuck in the how for more than 15 minutes. If you get stuck too long, you should ask for help. This is where the rules for asking questions can be helpful: provide context to what you’re trying to do, explain what things you tried, and show a concrete example. Eric Raymond has a great document “How to Ask Questions The Smart Way,” of which I would point to the “Be precise and informative about your problem” section.

As you grow your expertise, you won’t get stuck as much, or (more likely) when you do get stuck, you can get unstuck after doing a little bit of research on your own.

One time I asked a coworker how Java handles integer overflow. He said, “I don’t know, let’s try something,” and proceeded to write a quick unit test and used the IDE’s debugger to show the result. I felt sheepish because I realized I could have done this experiment on my own.

Programming can be a lot of fun when you can quickly write some code to prove/disprove a theory of how something will work.

Next, the why. I think a good example of this is clean coding. At some point, somebody wrote a bunch of spaghetti code, so now we have a best practice of writing modular code with loose coupling. At some point, somebody wrote the entire system using singletons, but then when it came time to maintain it, it was like dealing with a bunch of global variables, and nobody wants that. Now we know why injection is a common practice for dependency management. A mid-level developer understands clean coding and uses it in their own code, and a senior developer can get other people go along with clean coding practices.

In addition to the why of certain programming practices, there are processes or business decisions that it is helpful to understand the reasoning behind. For example, understanding the product vision. Who is the target audience for a particular feature? Are we trying to expand our product to new customers, or retain existing customers? When you know what lies behind the decisions that are handed down to you, you are able to make sense of the priorities of the business.

Sarah’s point about being senior is that a senior developer understands the why and is able to persuade others. To put it another way, it involves leadership. It’s not enough to have the right idea, you have to be able to motivate others to go along with you. It’s not enough to have the technical skills to write code. If you want to stand out as a senior developer, you need the soft skills to work with others and persuade them.

Taking the initiative

I came across an article by Vaggelis Giannikas about the 3 stages of being a Ph.D. student. Each stage involves taking more initiative and responsibility, and they lend themselves to comparison with what it means to be a mature software developer. Here are the 3 stages, reworded slightly for the non-academic world:

  1. I expect my boss to tell me what to do.
  2. I do my own research on the different options and go to my boss for advice on which one to pursue.
  3. I decide what to do and persuade my boss if s/he has any doubts.

Adapted from: XRDS Vol. 21, No. 3, Spring 2015, “The PH.D. Journey: Tips from somebody who managed to defend his thesis”

Growing as a software developer means moving from stage 1 to stage 2 to stage 3. In each stage, the software developer takes more initiative and also bears more responsibility for the outcome.

For example, in stage 1, a junior developer expects his boss to tell him what bugs to work on, and might throw in a few small features. The junior developer is mostly responsible for asking for more work, and the boss is responsible for reviewing what was done and making sure the right work is being done.

In stage 2, the boss has given a developer a larger feature, and the developer goes and researches 2 different solutions that would implement it. If the options are different technical choices, she might go to an architect for advice. If the options would have different product/user experience implications, she might go to a product manager for advice. The stage 2 developer is more proactive in getting the necessary information to make the decision.

Stage 3 represents someone who is an architect or product manager. They decide what to do and persuade the rest of the organization if they have doubts. Persuade is a great word here because it’s saying I can be a stage 3 developer without actually having the title that goes with that. In other words, even if I’m not a manager on the org chart, I can have that kind of influence on others. The stage 3 developer bases their decisions on their experience and expertise, and is responsible for impacting the organization in a positive way.

In conclusion, I liked this outline of what it means to grow as a Ph.D. student because it can be applied to becoming a mature software developer. As I grow in my ability to write code, I want to grow in my ability of seeking advice, making decisions, and persuading others.

How to make the most of a manager 1—1

The weekly manager one on one (1v1, 1:1, 1—1, choose your own punctuation) is a staple for office workers in contemporary corporate culture. Whether it’s weekly, every other week, or once a month, you’ll meet with your manager and have no idea what to say. At least, I didn’t know what to talk about.

When I started my career I had a few wrong assumptions about the weekly manager meeting. First, I assumed that the manager meeting should only happen when my manager sent me a calendar invitation. I ran into a situation where my weekly meeting suddenly disappeared off my calendar, and I assumed that this was an intentional cancellation. Three weeks later, I finally asked my manager about it, and he apologized for the lapse; he had not renewed the calendar invitation. I learned that if I had spoken up sooner, the problem would have been fixed right away.

Second, I assumed that the meeting had a specific agenda or desired outcome every week. I was a little frustrated about how open ended it was. My manager straightened me out, saying that often the agenda is just “let’s catch up.” I learned that this can still be valuable, just as a way of building a rapport and a relationship with my manager.

More recently I have come to realize that I can control the agenda in these meetings. If I plan ahead a little, I can think about what I want to talk about. There are a few areas that I’ve found valuable to bring up.

Managers are busy. They have other meetings, get hundreds of emails a day, and generally can’t keep track of everything going on around them. I found my manager one on one more valuable when I viewed it as an opportunity to make my manager aware of how I add value. I can help them by talking about the following:

  • Something I did successfully this past week
  • Talk about a time I helped someone with my expertise
  • Talk about how I’m completing my work on time, or if I’m my work is pushing beyond the estimate, why this is the case.
  • Talk about any advice I received, or any decisions I made.

Generating this kind of awareness or visibility can feel like self-promotion. However, I like to think of it as helping my manager be aware of the value I’m adding to the company. From a manager’s point of view, would you rather have to go pester each person and figure out what their doing? Or would you rather have them come to you and proactively give updates on how they’re kicking ass.

Another idea for the weekly manager meeting is to have a conversation. It’s a time slot in my week when I are not expected to be “heads down” coding. Instead of focusing on the quantitative, I can focus on the qualitative. I got this idea from the Hanselminutes episode “Speak up and present with confidence.

In this same vein, it is a chance to make sure I’m on the same page regarding any recent changes to projects I’m are working on. Was there an announcement that impacts my priorities? Did the process change? I can use the weekly meeting as an opportunity to make sure that I understand what is expected of me.

Hopefully these ideas help you like they helped me. Think of it this way: you’ll have that 30 minute time slot on your calendar regardless; why not make the most of it?

Quotable quotes 2

This post got me thinking: the structures that help people learn coding will also help experienced programmers be more productive.

Working in the head doesn’t scale. The head is a hardware platform that hasn’t been updated in millions of years. To enable the programmer to achieve increasingly complex feats of creativity, the environment must get the programmer out of her head, by providing an external imagination where the programmer can always be reacting to a work-in-progress.

Source: “Learnable Programming,” Bret Victor.

Office Politics 101 for Recovering Idealists. The article title says it all. I found this eye opening.

In the meantime, there’s a pretty easy rule of thumb to follow. When in doubt, keep it to yourself. Listen more than you speak and certainly more than you vent, collect as much information as possible, and ponder how it can be used to make yourself seem more of an asset to your boss than your competitors.

Source: “Office Politics 101 for Recovering Idealists”, Erik Dietrich.

I was encouraged to know that a pattern of thinking I sometimes slip into has a name. It also challenges me to overcome this distorted thinking so that I am no longer controlled by fear.

Catastrophizing essentially involves imagining and dwelling on the worst possible outcome of something. It’s basically overreacting and letting your thoughts run away to dire and highly unlikely scenarios. It’s the kind of thing that happens when you’re lying awake at three in the morning worried sick about the future and what’s going to happen to you.

Source: “Building Your Resiliency: Part VI – Quit Catastrophizing,” Brett & Kate McKay.

Patrick McKenzie with one take on a software career track. This article influenced me a lot:

Engineers are hired to create business value, not to program things:  Businesses … converge on doing things which increase revenue or reduce costs.  Status in well-run businesses generally is awarded to people who successfully take credit for doing one of these things.  (That can, but does not necessarily, entail actually doing them.)

Source: “Don’t Call Yourself A Programmer, And Other Career Advice,” Patrick McKenzie.

Quotable quotes

It would be arrogant of me to think that I have solved the problem of large-scale software development:

It is widely acknowledged that coordination of large scale software development is an extremely difficult and persistent problem.

Source: “Splitting the Organization and Integrating the Code: Conway’s Law Revisited,” Herbsleb and Grinter, 1999 (PDF).

One of the most common antipatterns of commercial software development:

In this evil, but extremely common, mirror universe, developers branch to create features. This branch stays isolated for a long time. Meanwhile, other developers are creating other branches. When it comes close to release time, all the branches get merged into trunk.

At this point, with a couple of weeks to go, the entire testing team that has been basically twiddling their thumbs finding the odd bug on trunk suddenly has a whole release worth of integration and system-level bugs to discover, as well as all the feature-level bugs which have not yet been found because nobody bothered to have the testers check the branches properly before they got integrated.

Source: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Humble and Farley, 2010.

This view is too optimistic for me, given what I know about human nature and our sinful condition:

Technological optimists believe that technology makes life better. According to this view, we live longer, have more freedom, enjoy more leisure. Technology enriches us with artifacts, knowledge, and potential. Coupled with capitalism, technology has become this extraordinary tool for human development. At this point, it is central to mankind’s mission. While technology does bring some unintended consequences, innovation itself will see us through.

Source: “The Moral Character of Cryptographic Work,” Rogaway, 2015 (PDF).

This article was how I first came across the work of Erik Dietrich. Since then I’ve had a lot of fun reading his articles on software development and office politics.

In the sense of skills acquisition, one generally realizes arrested development and remains at a static skill level due to one of two reasons: maxing out on aptitude or some kind willingness to cease meaningful improvement. … [L]et’s discard the first possibility (since most professional programmers wouldn’t max out at or before bare minimum competence) and consider an interesting, specific instance of the second: voluntarily ceasing to improve because of a belief that expert status has been reached and thus further improvement is not possible. This opting into indefinite mediocrity is the entry into an oblique phase in skills acquisition that I will call “Expert Beginner.”

Source: “How Developers Stop Learning: Rise of the Expert Beginner,” Erik Dietrich.

Computer security reading list (part 2)

I came across Bruce Schneier’s “CRYPTO-GRAM” many years ago when it was an email-only newsletter, and ever since then I’ve been interested in security. Taking St. Cloud State’s Computing Ethics class (CSCI 332) gave me more connections with how security affects computers.

Continuing my last post, Computer security reading list (part 1), this post includes some resources on computer security. Not that I’ve read everything linked to here, but I’ve read enough to be drawn in and informed. I hope that you may find these useful as well.

Blogs (continued)

  • Google Project Zero Project Zero is a team at Google that looks at different systems and finds and documents zero-day vulnerabilities.