Code Without Rules2024-01-09T15:35:59+00:00https://codewithoutrules.com/Itamar Turner-Trauringitamar@codewithoutrules.comFrom YAGNI to YDNIY2020-09-18T00:00:00+00:00https://codewithoutrules.com/2020/09/18/ydniy<p>How do you ship a product on schedule?
One useful approach is applying the You Ain’t Gonna Need It principle, or YAGNI for short: leave out all the things that seem nice-to-have, but you have no proof you actually need.</p>
<p>But beyond the things you don’t need, there are still plenty of features you pretty clearly do need… but are not blockers on releasing your product.
So beyond YAGNI, there’s also YDNIY: You Don’t Need It Yet.</p>
<p>Let’s see an example of this principle in practice, visualize the principle as a flowchart, and then compare it to another popular acronymed concept, the Minimum Viable Product.</p>
<!-- TEASER_END -->
<h2 id="a-real-world-example-shipping-a-new-memory-profiler">A real world example: shipping a new memory profiler</h2>
<p>In March 2020 I shipped the initial release of a new <a href="https://pythonspeed.com/products/filmemoryprofiler/">memory profiler for Python, Fil</a>.</p>
<p>Here’s how it changed over time in terms of features, from May to August 2020:</p>
<ul>
<li><strong>0.3.0, initial release:</strong> Installable via <code class="language-plaintext highlighter-rouge">pip</code> packaging tool, runs only on Linux, only profiles complete program runs.</li>
<li><strong>0.3.3:</strong> Support for an additional memory allocation API.</li>
<li><strong>0.4.0:</strong> Support for out-of-memory situations.</li>
<li><strong>0.5.0:</strong> macOS support.</li>
<li><strong>0.6.0:</strong> Support for <code class="language-plaintext highlighter-rouge">mmap()</code> allocation API.</li>
<li><strong>0.7.0:</strong> Support for C++ memory allocation API.</li>
<li><strong>0.9.0:</strong> Much faster and lower overhead in some use cases, added support for yet another memory allocation API.</li>
<li><strong>0.10.0:</strong> Support for running inside Jupyter notebooks, and native support for installing via the Conda packaging tool.</li>
</ul>
<p>All of the features I added in later releases were clearly necessary from the start; YAGNI did not apply.
Lots of people use macOS, the target audience of data scientists and scientists often use Conda and Jupyter, all those memory allocation APIs are used in the real world, and so on.</p>
<p>But even a tool that only runs complete programs on Linux, and only tracks the most popular memory allocation APIs, is still useful to some people.</p>
<p>If I had waited until all those features were implemented to ship an initial release, all the people who used the profiler during the first four months of its existence would have had to keep using worse tools.
And with every release, the number of people for whom the tool is useful has grown.</p>
<p>Unlike YAGNI, YDNIY doesn’t mean you don’t implement a feature—you just delay it so that you can release something now.</p>
<h2 id="the-yagni-and-ydniy-algorithm">The YAGNI and YDNIY algorithm</h2>
<p>Features that are not clearly necessary can be dropped based on the YAGNI principle.
And if the product is still useful without the feature, you can delay that feature based on the YDNIY principle.</p>
<p>In flowchart form:</p>
<div class="jekyll-diagrams diagrams graphviz">
<!-- Generated by graphviz version 2.43.0 (0)
-->
<!-- Title: G Pages: 1 -->
<svg width="574pt" height="291pt" viewBox="0.00 0.00 574.41 291.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 287)">
<title>G</title>
<polygon fill="white" stroke="transparent" points="-4,4 -4,-287 570.41,-287 570.41,4 -4,4" />
<!-- necessary -->
<g id="node1" class="node">
<title>necessary</title>
<polygon fill="none" stroke="black" points="360.52,-283 154.73,-265 360.52,-247 566.3,-265 360.52,-283" />
<text text-anchor="middle" x="360.52" y="-261.3" font-family="Rosario" font-size="14.00">Is the feature clearly needed?</text>
</g>
<!-- useful -->
<g id="node2" class="node">
<title>useful</title>
<polygon fill="none" stroke="black" points="221.52,-196 -0.02,-178 221.52,-160 443.05,-178 221.52,-196" />
<text text-anchor="middle" x="221.52" y="-174.3" font-family="Rosario" font-size="14.00">Is the product usable without it?</text>
</g>
<!-- necessary->useful -->
<g id="edge2" class="edge">
<title>necessary->useful</title>
<path fill="none" stroke="black" d="M335.99,-249C313.5,-235.25 280,-214.76 255.04,-199.5" />
<polygon fill="black" stroke="black" points="256.63,-196.37 246.27,-194.14 252.98,-202.34 256.63,-196.37" />
<text text-anchor="middle" x="315.52" y="-217.8" font-family="Rosario" font-size="14.00">  Yes</text>
</g>
<!-- YAGNI -->
<g id="node3" class="node">
<title>YAGNI</title>
<ellipse fill="none" stroke="black" cx="499.52" cy="-178" rx="38.19" ry="18" />
<text text-anchor="middle" x="499.52" y="-174.3" font-family="Rosario" font-size="14.00">YAGNI</text>
</g>
<!-- necessary->YAGNI -->
<g id="edge1" class="edge">
<title>necessary->YAGNI</title>
<path fill="none" stroke="black" d="M385.05,-249C408.23,-234.82 443.12,-213.49 468.28,-198.1" />
<polygon fill="black" stroke="black" points="470.36,-200.93 477.07,-192.73 466.71,-194.96 470.36,-200.93" />
<text text-anchor="middle" x="450.52" y="-217.8" font-family="Rosario" font-size="14.00"> No</text>
</g>
<!-- implement -->
<g id="node4" class="node">
<title>implement</title>
<ellipse fill="none" stroke="black" cx="198.52" cy="-91" rx="89.88" ry="18" />
<text text-anchor="middle" x="198.52" y="-87.3" font-family="Rosario" font-size="14.00">Implement it now</text>
</g>
<!-- useful->implement -->
<g id="edge3" class="edge">
<title>useful->implement</title>
<path fill="none" stroke="black" d="M216.97,-160.21C213.78,-148.41 209.44,-132.38 205.77,-118.82" />
<polygon fill="black" stroke="black" points="209.12,-117.79 203.13,-109.05 202.36,-119.62 209.12,-117.79" />
<text text-anchor="middle" x="223.52" y="-130.8" font-family="Rosario" font-size="14.00"> No</text>
</g>
<!-- YDNIY -->
<g id="node5" class="node">
<title>YDNIY</title>
<ellipse fill="none" stroke="black" cx="344.52" cy="-91" rx="38.19" ry="18" />
<text text-anchor="middle" x="344.52" y="-87.3" font-family="Rosario" font-size="14.00">YDNIY</text>
</g>
<!-- useful->YDNIY -->
<g id="edge4" class="edge">
<title>useful->YDNIY</title>
<path fill="none" stroke="black" d="M243.79,-161.61C263.84,-147.75 293.43,-127.31 315.35,-112.15" />
<polygon fill="black" stroke="black" points="317.4,-114.99 323.64,-106.43 313.42,-109.23 317.4,-114.99" />
<text text-anchor="middle" x="306.52" y="-130.8" font-family="Rosario" font-size="14.00">  Yes</text>
</g>
<!-- implement2 -->
<g id="node6" class="node">
<title>implement2</title>
<ellipse fill="none" stroke="black" cx="344.52" cy="-18" rx="91.78" ry="18" />
<text text-anchor="middle" x="344.52" y="-14.3" font-family="Rosario" font-size="14.00">Implement it later</text>
</g>
<!-- YDNIY->implement2 -->
<g id="edge5" class="edge">
<title>YDNIY->implement2</title>
<path fill="none" stroke="black" d="M344.52,-72.81C344.52,-64.79 344.52,-55.05 344.52,-46.07" />
<polygon fill="black" stroke="black" points="348.02,-46.03 344.52,-36.03 341.02,-46.03 348.02,-46.03" />
</g>
</g>
</svg>
</div>
<h2 id="yagni-and-ydniy-vs-mvp">YAGNI and YDNIY vs. MVP</h2>
<p>The Minimum Viable Product, or MVP, is another acronym that might seem like it means the same thing as YDNIY.
But as defined by its originator, Eric Ries, an MVP has a different goal, and actually adds on more work.</p>
<p>Specifically, <a href="https://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html">Ries defines an MVP</a> as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
He goes on to explain that a “MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.”</p>
<p>To put it another way, the goal of the MVP is to learn about users or customers, whereas the goal of YAGNI and YDNIY is to get something useful into users’ hands as quickly as possible.</p>
<br><hr>
<h3>Tired of scrambling to get your job done?<br><br>If you were productive enough, you could take the afternoon off, confident you’d produced high value work. Not to mention having an easier time finding a new job when you need one.<br><br>Learn the <a href="/secretskills/">secret skills of productive programmers</a>.</h3>
Find that bug! Using a search engine as a programmer2020-08-17T00:00:00+00:00https://codewithoutrules.com/2020/08/17/search-engine-programmers<p>Most bugs you encounter have been encountered by others before you; most programming problems you face have been faced by others as well.
And many of those people have written down details about what they’ve learned—in issue trackers, documentation, and blog posts.</p>
<p>All you have to do is find this information.</p>
<p>Typing a phrase in to your search engine of choice will sometimes take you straight to the right answer.
But quite often, the results aren’t helpful.</p>
<p>No need to give up, though: there are still plenty of ways you can productively keep searching.</p>
<h2 id="use-site-specific-search-too">Use site-specific search too</h2>
<p>It’s easy to believe that search engines have all the answers right at the top, but they actually hide quite a lot of content deep in their results.
And some obscure content never gets indexed at all, which is unfortunate when it’s the obscure content that you need to find.</p>
<p>So instead of just using a search engine, use the local search engine of the project issue tracker, the documentation, StackOverflow, and so on.</p>
<p>For example, let’s saying you’re using <a href="https://eliot.readthedocs.io">Eliot</a>, a somewhat obscure Python logging library I maintain, and you want to use it with the Pandas library.
Unfortunately, you get an error, so you search Google for the text of the error: <code class="language-plaintext highlighter-rouge">eliot dataframe is not json serializable</code>.
Now, there is an actual issue in Eliot’s GitHub issue tracker with this exact error message—but as of August 2020 Google doesn’t return it, probably because it didn’t bother to index that page.</p>
<p>But if you were to use the search form on the Eliot GitHub project’s issues page, you would find the issue that mentions this particular error.
In this case, as in many others, the search engine isn’t actually indexing everything: you have no choice but to use the local search engine.</p>
<p>Local search engines often have the additional benefit of allowing more structured search, for example:</p>
<ul>
<li>An issue tracker might let you search by open/closed status, labels, or the affected version.</li>
<li>StackOverflow questions are tagged with particular technologies by the person submitting the question.</li>
</ul>
<h2 id="you-still-want-to-use-a-search-engine">You still want to use a search engine</h2>
<p>A software project’s documentation and issue tracker are a great place to start searching, but sometimes you’ll find solutions elsewhere.</p>
<p>For example, if you have a problem with library A, it might be that project B had the same issue, and you can find a workaround in their issue tracker.
Or perhaps someone wrote a handy blog post on the issue—or they might have other related content.
And that related content can also be useful.</p>
<h2 id="read-results-that-dont-answer-your-question">Read results that don’t answer your question</h2>
<p>Often you’ll encounter results that solve a similar but not identical problem.
Read those pages anyway.</p>
<p>First, because you’ll learn more about the shape of the problem, broad approaches, and how the underlying software works.</p>
<p>Second, because you might find suggestions of new places to search.</p>
<p>Third, because this will give you an opportunity to apply your close reading skills and learn more domain-specific jargon.
You can then use this jargon to widen, narrow, and vary your search.</p>
<blockquote>
<p><strong>Note:</strong> This article is an excerpt from my book, <a href="/secretskills/"><em>The Secret Skills of Productive Programmers</em></a>, which also has a chapter on close reading.</p>
</blockquote>
<h2 id="narrow-and-widen-your-search">Narrow and widen your search</h2>
<p>Let’s say you’ve tried an initial search engine search, and you got a huge swath of unrelated results.
For example, if I use Google in private mode to search for <code class="language-plaintext highlighter-rouge">eliot</code>, I get many entries about the poet T.S. Eliot.</p>
<p>Given too many results, you need to focus in: add a keyword or two that will help narrow the results to those you care about.
In this example, searching for <code class="language-plaintext highlighter-rouge">eliot logging</code> find the actual Python library; searching for <code class="language-plaintext highlighter-rouge">eliot python</code> also helps.</p>
<p>Again, the jargon you’ve found along the way will help you know what to add.</p>
<p>If your search is too specific, you can do the opposite, removing some unnecessary keywords.</p>
<h2 id="try-lots-of-variations-by-using-jargon">Try lots of variations by using jargon</h2>
<p>Even if your initial searches don’t work, you shouldn’t give up: now is the time to start using synonyms and alternative phrasings.
You are using a certain phrase to describe the problem, but other people might conceptualize it a different way, and use different phrases.</p>
<p>If you can rephrase the search you are likely to find many results you haven’t seen before.
For example, let’s say you’re using the Pandas dataframe library for Python and you’re <a href="https://pythonspeed.com/datascience/">running out of memory</a>.
If you search for <code class="language-plaintext highlighter-rouge">pandas too much memory</code>, <code class="language-plaintext highlighter-rouge">pandas out of memory</code>, <code class="language-plaintext highlighter-rouge">pandas large files</code>, and <code class="language-plaintext highlighter-rouge">pandas out of core</code> will give you some overlapping results, but each returns some results you won’t get from other phrases.</p>
<p>The last term comes from “out-of-core computation”, a computer science term for algorithms that process data that doesn’t fit in memory.
How might you learn about that phrase?
By collecting jargon as you go along.</p>
<h2 id="search-for-errors-the-right-way">Search for errors the right way</h2>
<p>When searching for errors, you need to copy/paste enough that you’re identifying the specific error, but not too much such that the search engine can’t find any matching results.
For example:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Traceback (most recent call last):
File "/home/itamarst/flask/app.py", line 2446, in wsgi_app
response = self.full_dispatch_request()
File "/home/itamarst/flask/app.py", line 1951, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/home/itamarst/flask/app.py", line 1820, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/home/itamarst/flask/_compat.py", line 39, in reraise
raise value
File "/home/itamarst/flask/app.py", line 1949, in full_dispatch_request
rv = self.dispatch_request()
File "/home/itamarst/flask/app.py", line 1935, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
File "flask1.py", line 18, in index
return _counter + "\n"
TypeError: unsupported operand type(s) for +: 'Counter' and 'str'
</code></pre></div></div>
<p>Different languages will have different formatting, but the basic idea is that the lines that includes directories are specific to your computer.
Searching for <code class="language-plaintext highlighter-rouge">/home/itamarst</code> is not going to get good results!</p>
<p>Searching for the last line might work:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>TypeError: unsupported operand type(s) for +: 'Counter' and 'str'
</code></pre></div></div>
<p>Or maybe the last two lines, if that line is from code I downloaded and didn’t write myself:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code> return _counter + "\n"
TypeError: unsupported operand type(s) for +: 'Counter' and 'str'
</code></pre></div></div>
<p>Or perhaps I want to understand the generic error, rather than this particular instance:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>TypeError: unsupported operand type(s) for +:
</code></pre></div></div>
<p>Or perhaps I think this is a problem in the Flask library rather than my code, in which case I might search for:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>flask TypeError: unsupported operand type(s) for +: 'Counter' and 'str'
</code></pre></div></div>
<p>Typically the important information will be either at the beginning or the end of the error traceback or stacktrace.</p>
<p>(Thanks to <a href="https://www.codewithjason.com/">Jason Swett</a> for suggesting this technique.)</p>
<h2 id="finally-be-careful">Finally, be careful</h2>
<p>One issue with searching for random solutions on the web is that the proposed solution is sometimes wrong or broken.
I’ve seen people propose insecure solutions on StackOverflow, and then get upvoted by other people who don’t know any better.</p>
<p>Just because the solution seems to work doesn’t mean it’s correct: you still have to think, do some additional research to validate the proposal, and probably write some tests too.</p>
<p><strong>Want more ways to become a more productive programmer?</strong>
This article is an excerpt from my book, <a href="/secretskills/"><em>The Secret Skills of Productive Programmers</em></a>.</p>
<br><hr>
<h3>Tired of scrambling to get your job done?<br><br>If you were productive enough, you could take the afternoon off, confident you’d produced high value work. Not to mention having an easier time finding a new job when you need one.<br><br>Learn the <a href="/secretskills/">secret skills of productive programmers</a>.</h3>
Your dev environment matters less than you think2020-06-25T00:00:00+00:00https://codewithoutrules.com/2020/06/25/dev-environment<p>How do you setup your dev environment?
Depending on your language there are many choices of editor, package manager, build tool, linter, on and on.
And every article you find will have a different combination of suggested tools, each of which claiming that <em>their</em> list is The Right Way To Do Things.</p>
<p>So which do you choose?</p>
<p>The short answer: it doesn’t matter.
Your choice of dev environment is meaningless.</p>
<p>The slightly less flippant answer is that, yes, there are some contraints on which tools you should pick, but otherwise you should just pick something and move on.</p>
<p>Let’s see why dev environments don’t matter that much in the end, and what limited constraints you should apply when choosing your tools.</p>
<!-- TEASER_END -->
<h2 id="learning-how-to-cook">Learning how to cook</h2>
<p>Imagine you’re training to become a chef.
You will need to learn how to use a knife correctly, to chop and dice safely and quickly.</p>
<p>And yes, you need a sharp knife.
But when you’re starting out, it doesn’t matter which knife you use: just pick something sharp and good enough, and move on.
After all, the knife is just a tool.</p>
<p>The people eating the food you cook don’t care about which knife you used: they care how the food tastes and looks.</p>
<p>After six months in the kitchen, you’ll start understanding how you personally use a knife, what cuisines you want to pursue, what techniques you want to vary.
And then you’ll have the knowledge to pick a specific knife or knives exactly suited to your needs.</p>
<p>But remember: the people eating your food <em>still</em> won’t care which knife you used.</p>
<h2 id="choosing-a-dev-environment">Choosing a dev environment</h2>
<p>When you use a website, you don’t care which build tool the programmer used.
When you run an app, you don’t care which editor they used.
You want the software to work, to do what it says, to be easy to use, to get out of your way—and you don’t care how they did it.</p>
<p>And that applies just as much to the users of your code: they don’t care which tools you used.</p>
<p>And when you’re starting out, whether programming in general or a new language or framework, you don’t know how you will like to work.
So instead of obsessing over finding the ideal development environment and toolchain, just pick tools that are good enough:</p>
<ul>
<li><strong>Popular:</strong> So you can easily find help.</li>
<li><strong>Easy to get going:</strong> Your goal is ship useful code, and as a beginner time spent fiddling with your dev environment won’t help with that.</li>
</ul>
<p>Once you have enough experience, you will start developing opinions.
You might become choosy about which tools you use, or end up customizing them to your needs.
You might even write an article about your particular dev environment and favorite tools.</p>
<p>But however strong your preferences are, chances are that given tools you don’t quite like as much, you will still do just fine.
If you know what you’re doing, you can chop vegetables with any sharp knife, even if it’s not your favorite.</p>
<br><hr>
<h3>Tired of scrambling to get your job done?<br><br>If you were productive enough, you could take the afternoon off, confident you’d produced high value work. Not to mention having an easier time finding a new job when you need one.<br><br>Learn the <a href="/secretskills/">secret skills of productive programmers</a>.</h3>
To get a better programming job, explain your problem-solving skills2020-05-18T00:00:00+00:00https://codewithoutrules.com/2020/05/18/job-search-skills<p>When you’re looking for a new programming job, how do you explain your value?
The usual approach is a long list of technologies, but this leaves out a critical skill: your ability to solve problems.</p>
<p>If you can convey your level of skill at problem solving, you can get:</p>
<ul>
<li>More job offers.</li>
<li>Jobs with technologies you don’t know.</li>
<li>A higher salary by getting slotted into a higher pay grade.</li>
</ul>
<p>Often just a few extra words can make a big difference in demonstrating your skills.
Let’s see how you can do it.</p>
<!-- TEASER_END -->
<h2 id="three-levels-of-problem-solving-skills">Three levels of problem solving skills</h2>
<p>As I discussed elsewhere <a href="/2018/10/10/beyond-senior-software-engineer/">in more detail</a>, problem solving comes in three stages, each approximately corresponding to a particular career stage (these names are due to <a href="https://rkoutnik.com/2016/04/21/implementers-solvers-and-finders.html">Randall Koutnik</a>):</p>
<ol>
<li>Staff or principal software engineers are <em>Finders</em>: they find new problems.</li>
<li>Senior software engineers are <em>Solvers</em>: they solve already-identified problems.</li>
<li>Junior software engineers are <em>Implementers</em>: they implement already-identified solutions.</li>
</ol>
<p>The earlier you are in the problem-solving process, <a href="/2020/04/20/productivity-skills/">the more productive you are</a>, and therefore the more valuable as an employee.</p>
<p><strong>As a result, you need to communicate how advanced your skill is across these three levels to demonstrate your productivity.</strong>
Everything from your resume to the stories you tell in interviews should communicate your level of skill.</p>
<h2 id="explaining-your-skill-level">Explaining your skill level</h2>
<p>Explaining your skill level involves telling stories that use the correct words and sufficient information to demonstrate your skill.
I’m going to use resumes as an example here, but you should ensure you do this in interviews as well—if you’re practicing with a friend, make sure they’re checking for this, it’s easy to leave the information out.</p>
<p>Consider the following entry from a resume:</p>
<blockquote>
<p>Moved deployment from manually-managed hosts to a new Kubernetes cluster.</p>
</blockquote>
<p>This experience entry uses an implementation-level verb: “moved”.
Similarly, “coded”, “tested”, “wrote”, “fixed”, “optimized”—these are all about implementation.
And maybe it’s implementation was tricky and difficult, and it’s good to convey that, but if you also solved the problem or identified the problem it’s impossible to tell from this phrasing.</p>
<p>Any task you write about in your resume and talk about in interviews was the result of someone identifying a problem, and someone coming up with the solution.
If it was you, <em>make sure you say that</em>.</p>
<p>Let’s say in our example above you were the one tasked with figuring out an alternative to manually-managed hosts.
If so, you need to add additional context and verbs that convey that:</p>
<blockquote>
<p>Investigated alternatives to manually-managed hosts, decided on Kubernetes, and moved the deployment to a new cluster.</p>
</blockquote>
<p>Now we can clearly see you solved the problem.</p>
<p>If you were the one who identified the problem, again you need to make sure you explicitly call that out:</p>
<blockquote>
<p>Identified manually-managed hosts as an operational problem, and got management buy-in to change to a better system.
Subsequently investigated alternatives, decided on Kubernetes, and moved the deployment to a new cluster.</p>
</blockquote>
<p>Now we can see all the value you provided.</p>
<p>If you only identified a problem, that’s fine too, just say so:</p>
<blockquote>
<p>Noticed a critical customer-facing bug that was impacting many users; after the team responsible for that area fixed it, they reported a $300,000 increase in revenue as a result.</p>
</blockquote>
<h2 id="communicating-value-at-different-career-stages">Communicating value at different career stages</h2>
<p>Now that you’ve seen how to phrase your skill level, let’s see how this works at different career stages.</p>
<h3 id="implementers">Implementers</h3>
<p>When you’re at the start of your career you will mostly be implementing other people’s solutions.
However, in one or two cases you might be starting to solve problems, or even find problems.
Make sure your resume highlights those instances, however small.</p>
<p>Sometimes this will happen in non-programming contexts.
For example, I knew one early stage software engineer who made very insightful suggestions about hiring.
Mention it anyway.</p>
<p>If you had another career before switching to programming, you’ll likely have plenty of examples.
Make sure to highlight those even if they’re unrelated to coding; those problem-finding and solving skills will at least partially transfer.</p>
<h3 id="solvers">Solvers</h3>
<p>If you can solve problems on your own, you want to both:</p>
<ol>
<li>Communicate this fact.</li>
<li>Highlight the places where you did identify problems, even if it’s happened in only a few cases.</li>
</ol>
<p>Review your resume and make sure all the relevant entries explicitly talk about the ways in which you came up with the solution.
If you already have a suitable job title, like senior software engineer, then getting the phrasing right isn’t quite as important—but it’s still worth doing.</p>
<p>If you still have a junior job title but your skills have progressed, it’s doubly important to ensure you’re highlighting your problems solving skills.</p>
<p>Once you’ve done that, try to expand on any places where you were involved in identifying problems.</p>
<h3 id="finders">Finders</h3>
<p>Your goal as a Finder is to ensure you’re not confused with a Solver.
It’s very easy to phrase things in a way that doesn’t make clear you identified the problem—after all, identifying the problem may only have a taken a few minutes.</p>
<p><strong>But those initial few minutes where you noticed something needs to be done are quite often the most value parts of the whole process, so make sure you explicitly talk about finding the problem.</strong>
This is even more important if your current job title doesn’t reflect your actual level of skill.</p>
<h2 id="what-to-do-next">What to do next</h2>
<p>Even if submitting resumes isn’t the best way to find a job, you still need one, and writing it is a good way to rehearse for an interview.</p>
<p><strong>So get your resume out, and for each experience entry make sure it’s clear whether you implemented the solution, solved the problem, and/or found the problem.</strong>
This will take you an hour, no more, and at the end of this process you’ll have a much easier time communicating some of your most valuable non-technological skills.</p>
<p>And if you’d like to learn some more of those skills, check out my new book, <em><a href="/secretskills/">The Secret Skills of Productive Programmers</a></em>.</p>
<br><hr>
<h3>Tired of scrambling to get your job done?<br><br>If you were productive enough, you could take the afternoon off, confident you’d produced high value work. Not to mention having an easier time finding a new job when you need one.<br><br>Learn the <a href="/secretskills/">secret skills of productive programmers</a>.</h3>
How to prepare for losing your programming job2020-05-14T00:00:00+00:00https://codewithoutrules.com/2020/05/14/prepare-losing-job<p>Another week has passed, and another 3 million people in the US have filed for unemployment.
While the current situation hasn’t impacted programming jobs quite as much, it’s just a matter of time before the economic damage hits most everywhere.
There will be layoffs, and plenty of them, and occasionally whole companies shutting down.</p>
<p>So even if your job is secure now, you might still lose it in the future.
How can you prepare?
What can you do to reduce your future risks?</p>
<p>The first thing you need to do is come up with a plan, which is what this article is all about.
In particular, you will want to:</p>
<ul>
<li>Try to make sure you have the necessary financial resources.</li>
<li>Make your future job hunt easier, by building a network, making sure your skills are up-to-date, and making sure you have visible public proof of your skills.</li>
<li>Come up with a series of fallback plans if things don’t go well.</li>
</ul>
<p>Let’s go over these one-by-one.</p>
<!-- TEASER_END -->
<h2 id="money-in-the-bank">Money in the bank</h2>
<p>If you lose your job, you lose your paycheck—but you still have to pay your bills.
And after the dot-com bust, the last big tech recession, it took years for all the jobs to come back</p>
<p>If you have at least six months of living expenses <em>in cash</em>, that’s a good start.
If not, it’s best to think about how to get there.</p>
<p>There are two sides to this:</p>
<ol>
<li>If possible, you need to cut your expenses, which will both allow you to save and reduce how much money you need for each unsalaried month. See <a href="/2016/08/08/living-below-your-means/">this more detailed article</a>.</li>
<li>Ensuring your financial assets, if you have any, aren’t correlated with your job.
<ol>
<li>If you own stock in your own company, you are making a double bet: if the company goes down, you will lose money and your job.</li>
<li>If you work for a startup that needs to raise money soon, a crashing stock market will also greatly reduce the viability of your current job.</li>
<li>More broadly, if you own stocks and to a lesser extent corporate bonds, how correlated are they with your ability to keep a job?</li>
<li>Even more broadly, how much of your net worth is tied to the tech industry, or the economy as a whole?</li>
</ol>
</li>
</ol>
<p>In short, you want cash on hand, and plenty of it.</p>
<h2 id="making-your-future-job-hunt-easier">Making your future job hunt easier</h2>
<p>Searching for a job will be much easier if you:</p>
<ul>
<li>Know lots of people.</li>
<li>Have useful skills.</li>
<li>Can visibly demonstrate you have those skills.</li>
</ul>
<p>Let’s cover those one by one.</p>
<h3 id="knowing-lots-of-people">Knowing lots of people</h3>
<p>Applying for a job by sending in your resume is the hardest way to get hired.
It’s much easier if you know someone who can vouch for you, can get you past the initial screen, or can fill you in on what the hiring manager really wants.</p>
<p>So the more people you know, the better off you are.
Elsewhere I have <a href="/2018/05/08/networking/">a guest post about (social) networking</a>, but that can take time and is harder during a pandemic.
But there are still a few easy things you can do in the short term:</p>
<ul>
<li>Join a public Slack or two for the technology area you specialize in.
You can help answer people’s questions, see when people mention they’re hiring, and more broadly get a better sense of the zeitgeist, which is useful for building your skills (see below).</li>
<li>Keep the contact info for former co-workers.
This can be done via LinkedIn, for example, and often there will be an ex-employee Slack.
If there isn’t one, you can start it—especially if your company is having initial rounds of layoffs.
This too can often be very educational, as former employees might be more forthcoming.</li>
<li>Find ways to help other people.
Can you teach useful skills?
Join a <a href="https://www.mutualaidhub.org/">local mutual aid organization</a>?</li>
</ul>
<h3 id="build-useful-skills">Build useful skills</h3>
<p>If you’ve been working at the same job for a while, it’s easy for your technical skills to get a little stale.
Unless you’re working at the right place, hang out with the right people, or do the right things, you might not be aware of the latest technology, or you might be using out-of-date practices.</p>
<p>So you’ll want to update your skills a little.
As always, doing this extensively outside of your job may not be possible, so try to:</p>
<ol>
<li>Spend an hour a week, ideally during work hours, getting up-to-date on the latest technologies.
The goal here is breadth, not depth: sign up for a newsletter for your technology stack (<a href="https://github.com/zudochkin/awesome-newsletters">he’s a partial list</a>), skim the topics at a relevant conference, maybe watch a talk or two.
I cover <a href="/2019/03/29/learn-new-technologies/">learning for breadth here</a>, but the basic idea is that knowing a tool exists and what it does can take very little time, and is quite valuable on its own: both on the job, but also in interviews (“I haven’t used it myself, but I believe tool X is how you would solve this”).</li>
<li>Try to <a href="/2017/10/23/obsolete-skills/">learn more technologies on the job</a>, because <a href="/2017/09/09/learn-a-new-programming-language/">that is the best place to do so</a>.</li>
</ol>
<h3 id="create-visible-proof-of-skills">Create visible proof of skills</h3>
<p>Having skills is one thing, proving you have them is another.
It is therefore quite useful during a job hunt to have some visible, public proof you have these skills.
For example:</p>
<p><strong>Open source:</strong> When I moved to the US in my 20s, my work on an open source project made it much easier for me to get job interviews, and eventually job offers.
It wasn’t just that my resume said that I knew computer networking, I could point to a publicly available project used by real people and say “I worked on that”.</p>
<p>Even if you share code that isn’t widely used, it can still be useful as proof of skill.</p>
<p><strong>Conference talks:</strong> Speaking publicly about a particular skill, technology, or project is a great way to get public proof of skills.
With conferences moving online, speaking at conferences is now much easier.
You don’t have to travel or pay for you travel, and you don’t have to get approval from your manager to lose work.
If there’s a topic where you know enough to help someone else, look for conferences on the topic and submit a proposal.</p>
<p><strong>Blogging:</strong> Have something to share, or learning something new? Write it down and share it publicly.
Writing well is an immensely useful skill in general, so this will also count as improving your skills.
You can write for your own blog, or you can propose a blog post on your company’s tech blog, if they have one.</p>
<h2 id="fallback-plans">Fallback plans</h2>
<p>In an ideal world you would lose your job, start a job search, find a new job within a month, and everything will be fine.
Sadly we don’t always live in an ideal world.</p>
<p>So if you live in a country like the US that a shitty social net it’s worth coming up with a series of fallback plans, if only for your own peace of mind.</p>
<p>For example, how can you make your money last longer?</p>
<ol>
<li>As soon as you lose your job, apply for unemployment.</li>
<li>Cut additional costs.</li>
<li>If time stretches on and you still don’t have a job, figure out ways to reduce housing costs. Are you young and have the ability to move back in with your parents? Have more room than you need and the option of adding roommates? All in a pandemic-safe way, of course.</li>
<li>Any ways you can make money some other way, if it’s really taking too long?</li>
</ol>
<p>If you can’t find a job immediately, you will have probably have more time to upgrade your skills.</p>
<ol>
<li>Which skills are worth working on?</li>
<li>What’s the best way to improve them?</li>
</ol>
<p>You’ll also want to meet more people who can help you find a job.</p>
<ol>
<li>Can you go to online meetups?</li>
<li>Find more places to interact with people online?</li>
</ol>
<p>Write this all down, and when you’re worried you’ll at least have the comfort of knowing there will be some things you can do if and when your job goes away.</p>
<h2 id="were-all-in-this-together">We’re all in this together</h2>
<p>As with most big problems, there is only so much you can do as an individual: to meaningfully improve the situations we need to work together, whether in mutual aid groups or via political organization.
On the other hand, you need to ensure that you as an individual are doing OK; you can’t help others if you’re collapsing under your own troubles.</p>
<p>And since this can all be overwhelming, start with a few simple actions:</p>
<ol>
<li>Cut an expense or two.</li>
<li>Get in touch with some old co-workers.</li>
<li>Sign up for a newsletter.</li>
<li>Start writing down your fallback plans.</li>
</ol>
<p>And then, once you have things under control emotionally, when you have a plan and you know what you’re doing next, start thinking about how you can help others, and work with other people to improve things for everyone.</p>
<br><hr>
<h3>Tired of scrambling to get your job done?<br><br>If you were productive enough, you could take the afternoon off, confident you’d produced high value work. Not to mention having an easier time finding a new job when you need one.<br><br>Learn the <a href="/secretskills/">secret skills of productive programmers</a>.</h3>
The secret skills of productive programmers2020-04-20T00:00:00+00:00https://codewithoutrules.com/2020/04/20/productivity-skills<p>This article was written during abnormal circumstances, with much of the planet under lockdown due to the COVID-19 pandemic.
Parents with children at home have far less time, and pretty much everyone is feeling stressed and distracted.</p>
<p>Under more normal circumstances there are only so many hours in the day to do your job; now it’s even worse.
And yet work needs to get done: code needs to get written, features need to be shipped, bugs need to be fixed.</p>
<p><strong>Faced with an ever growing list of tasks, how do you get everything done?</strong></p>
<p>The short answer is, you can’t.
You will never get everything done.</p>
<p>What you can do, though, is choose the <em>right</em> work, the most valuable work, the most useful work, the work with most leverage.
<strong>Choose the right work and you can gets orders of magnitude improvement in your output.</strong></p>
<p>Let’s see how.</p>
<!-- TEASER_END -->
<h2 id="the-goal-increased-output">The goal: increased output</h2>
<p>Your output as a programmer is based both on your productivity and on how much time you work:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Output = Productivity × Time Worked
</code></pre></div></div>
<p>The first thing to notice is that there is a hard limit on how much increasing your working hours can help.
After all, there are only 168 hours in a week.</p>
<p>If you never slept, ate, or did anything but work—and this will literally kill you—you can work 4.2× as much as a 40-hour workweek, and that’s it.
And even with smaller increases in work hours, the gains quickly decline.
As you work more hours you’ll become fatigued and make more mistakes; beyond a certain point those extra work hours will decrease your productivity, canceling out any gains.</p>
<h2 id="what-is-output-for-a-programmer">What is output for a programmer?</h2>
<p>Since increasing working hours isn’t really an option, the key to increasing your output is increasing your productivity.
Productivity is the output you produce in each fixed unit of time, for example:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Productivity = Output per week
</code></pre></div></div>
<p><strong>If you’re going to improve your productivity, you need to understand how to measure output.</strong></p>
<p>The obvious measure is how much code you write: the more code, the better.
This measure is obvious, popular, and completely wrong.</p>
<p>All other things being equal, is it better to implement the same feature with 10 lines of code, or 10,000 lines of code?
If we measure output by code produced, the latter solution is better, but in most cases a 10 line solution is preferable to 10,000 lines.
More code means higher maintenance costs, not to mention more opportunities for defects.</p>
<p><strong>Your job as a programmer is not writing code, your job is <em>solving problems</em>: software is a tool, a means to an end.</strong>
Software becomes valuable because of the problems it solves.</p>
<p>As a rough measure, your output as a programmer can be measured by the problems you solve: the more significant the problems you can solve, the better.</p>
<p>If you work for a business, significance eventually translates directly or indirectly into monetary terms: money made or money saved.
In other areas you can come up with domain-specific concrete measures of usefulness: number of people served, carbon emissions reduced, number of scientists using your software, and so on.</p>
<blockquote>
<p><strong>Note:</strong> If the problems you solve produce negative value you will become anti-productive: the better you are at your job, the more damage you will cause.</p>
<p>If making money hurts people or the environment, your work may be productive for your employer but anti-productive for society as a whole.
So make sure you’re carefully considering the ethical consequences of your actions as a worker.</p>
</blockquote>
<h2 id="how-to-increase-productivity">How to increase productivity</h2>
<p>Given the above, here’s how you can increase your productivity:</p>
<ol>
<li>Find the most significant problem you can work on.</li>
<li>Come up with the most efficient solution to that problem.</li>
<li>Implement the solution with minimum wasted time.</li>
</ol>
<p>Let’s go through these steps one by one, and see why they’re key to productivity.</p>
<h3 id="1-find-the-most-significant-problem">1. Find the most significant problem</h3>
<p>Let’s consider our formula for productivity again:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Productivity = Significant problems solved / Week
</code></pre></div></div>
<p>There are many problems you could be working on, so first you have to choose one.
If you could solve either of these problems, should you be working on:</p>
<ol>
<li>Implementing a particular missing feature; this will increase revenue by $50,000.</li>
<li>Fixing a bug that was decreasing customer retention; this will increase revenue by $1,000,000.</li>
</ol>
<p>All other things being equal, the second problem is obviously the one you should be focusing on.
Even if it takes 10× as long to solve and implement that bug fix, it should still be the highest priority:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Productivity of #1 = $50,000 / 1 Week = $50,000 / Week
Productivity of #2 = $1,000,000 / 10 Weeks = $100,000 / Week
</code></pre></div></div>
<p><strong>Here’s the issue: in order to fix that expensive bug and improve customer retention, you need to know the problem exists.</strong>
If no one ever notices that customers are leaving, if no one ever finds that bug, if no one realizes the connection between the two—then that problem will never be solved.</p>
<p>And that’s why finding problems is the first and most valuable step in increasing productivity.</p>
<h3 id="2-come-up-with-an-efficient-solution">2. Come up with an efficient solution</h3>
<p>Once you’ve identified the most significant problem—or once your manager assigns you a problem they identified—you need to come up with a solution.</p>
<p>Which solution do you think is better?</p>
<ol>
<li>Takes 1000 lines of code and 4 weeks to implement.</li>
<li>Takes 100 lines of code and 3 days to implement.</li>
</ol>
<p>All other things being equal, the second solution is obviously better.
But again, you need to <em>find</em> that solution.</p>
<p>If you only ever find that first solution, then no matter how efficiently you implement it, no matter how focused you are, no matter how much you manage to speed things up—you’re still implementing a much less efficient solution.</p>
<p>And that’s why identifying better solution is the second most valuable step in increasing productivity.</p>
<h3 id="3-implement-the-solution-without-wasting-a-time">3. Implement the solution without wasting a time</h3>
<p>Once you’ve identified a problem and chosen the solution, there is only so much leverage you have to improve productivity.
You obviously want to avoid getting stuck and spinning your wheels, because wasted time reduces your productivity.</p>
<p>But given a particular solution, there’s only so much waste you can reduce, only so fast you can go:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Wasted time → $50,000 / 2 weeks = $25,000 / week
No waste → $50,000 / 1 week = $50,000 / week
</code></pre></div></div>
<p>Efficient implementation is the last and least valuable way of increasing productivity.</p>
<h2 id="technological-skills-arent-enough">Technological skills aren’t enough</h2>
<p>While you get the most increased productivity from identifying problems and the least from efficient implementation, your career as a programmer progresses in the opposite direction:</p>
<ol>
<li>Junior engineers implement solutions.</li>
<li>Senior engineers find solutions and implement them.</li>
<li>Principal or staff engineers identify problems, find solutions, and implement them.</li>
</ol>
<p><strong>So becoming more productive isn’t just about helping your employer’s bottom line, it’s also about learning the skills that will give you more pay and more influence.</strong></p>
<p>Critically, technological skills are necessary but not sufficient to increase your productivity:</p>
<ul>
<li>Your JavaScript skills don’t matter if you can never meet deadlines.</li>
<li>Your testing skills don’t matter if you can’t convince your manager of the value of testing.</li>
<li>Your software architecture skills don’t matter if no one has ever heard of your product.</li>
</ul>
<h2 id="why-these-skills-are-secret">Why these skills are “secret”</h2>
<p>Most discussions of programming productivity tend to end up focusing purely on technology, coding, and design skills, and skip over these problem-solving skills.
Of course, this isn’t a conspiracy of silence, no one is deliberately hiding the existence of the skills.</p>
<p>My guess is that experienced programmers still have to learn new technologies, so they’re more likely to realize the need to explain those particular skills.
But having learned them once, they apply skills like timeboxing, or considering multiple different solutions to a problem, without even noticing they’re doing it.
And so they end up talking about problem-solving skills rather less, and about technological skills rather more.</p>
<h3 id="how-do-you-learn-these-skills">How do you learn these skills?</h3>
<p><strong>This article is an excerpt from my book, <a href="/secretskills/">The Secret Skills of Productive Programmers</a>, covering the non-technical skills you need to get better at identifying problems, solving problems, and implementing them on schedule.</strong></p>
<p>Elsewhere on this site you’ll find many free articles on building up your skills.</p>
<br><hr>
<h3>Tired of scrambling to get your job done?<br><br>If you were productive enough, you could take the afternoon off, confident you’d produced high value work. Not to mention having an easier time finding a new job when you need one.<br><br>Learn the <a href="/secretskills/">secret skills of productive programmers</a>.</h3>
Job negotiation for programmers: the basic principles2019-11-27T00:00:00+00:00https://codewithoutrules.com/2019/11/27/job-negotiation-for-programmers<p>You need to negotiate at a new job: for your salary, or benefits, or my personal favorite, a shorter workweek.
You’re not sure what to do, or how to approach it, or what to say when the company says “how much do you want?” or “here’s our offer—what do you say?”</p>
<p>Here’s the thing: that final conversation about salary might be the most nerve-wracking part, but the negotiation process starts much much earlier.
<strong>Which means you can enter that final conversation having positioned yourself for success—and feeling less stressed about it too.</strong></p>
<p>The way you can do that is following certain basic principles, which I’ll be covering in this article.
I’m going to be focusing on salary negotiation as an example, but the same principles will apply when negotiating for a shorter workweek.</p>
<p>In particular, I’ll be talking about:</p>
<ol>
<li>An example from early in my career when I negotiated very very badly.</li>
<li>The right way to negotiate, based on four principles:
<ol>
<li>Employment is a negotiated relationship.</li>
<li>Knowledge is power.</li>
<li>Negotiate from a position of strength.</li>
<li>Use the right tactics.</li>
</ol>
</li>
</ol>
<!-- TEASER_END -->
<h2 id="the-wrong-way-to-negotiate">The wrong way to negotiate</h2>
<p>Before moving on to the principles of negotiation, let me share a story of how I negotiated badly.</p>
<blockquote>
<p>During my first real job search I interviewed at a company in New York City that was building a financial trading platform.
They were pretty excited about some specific technologies I’d learned while working on Twisted, an open source networking framework.
They offered me a job, I accepted, and my job search was over.</p>
<p>But then they sent me their intellectual property agreement, and I actually read legal documents; you should read them too.
The agreement would have given the company ownership over any open source work I did, including work on Twisted.
I wanted to ensure I could keep doing open source development, especially given that was their reason for hiring me in the first place.
I asked for an exemption covering Twisted, they wouldn’t agree, and so we went back and forth trying to reach an agreement.</p>
<p>Eventually they came back with a new offer: in return for not working on Twisted I’d get a 20% salary increase over their initial offer.
I thought about it briefly, then said no and walked away from the job.
Since I had neither a CS degree—I’d dropped out—nor much of an employment history, open source contribution was important to my career.
It was how I’d gotten contracting work, and it was the reason they’d offered me this job.
And I enjoyed doing it, too, so I wasn’t willing to give it up.</p>
<p>I posted about this experience online, and an employee of ITA Software, which was based in the Boston area, suggested they were happy to support contributions to open source projects.
It seemed worth a try, so I applied for the position.
And when eventually I got a job offer from ITA and they asked me for my salary requirements, I asked for the second offer I’d gotten, the one that was 20% higher than my original offer.
They accepted, and I’ve lived in the Boston area ever since.</p>
</blockquote>
<p>As we go through the principles below, I’ll come back to this story and point out how they were (mis)applied in my two negotiations.</p>
<h2 id="the-four-principles-of-negotiation">The four principles of negotiation</h2>
<p>You can think of the negotiation process as building on four principles:</p>
<ol>
<li>Employment is a negotiated relationship.</li>
<li>Knowledge is power.</li>
<li>Negotiate from a position of strength.</li>
<li>Use the right tactics.</li>
</ol>
<p>Let’s go through them one by one.</p>
<h3 id="principle-1-employment-is-a-negotiated-relationship">Principle #1: Employment is a negotiated relationship</h3>
<p>If you’re an employee, your employment relationship was negotiated.
When you got a job offer and accepted it, that was a negotiation, even if you didn’t push back at all.
Your choice isn’t between negotiating and not negotiating: it’s between negotiating badly, or negotiating well.</p>
<h4 id="negotiate-actively">Negotiate actively</h4>
<p>If you don’t actively try to negotiate, if you don’t ask for what you want, if you don’t ask for what you’re <em>worth</em>—you’re unlikely to get it.
Salaries, for example, are a place where your interests and your employer’s are very much at odds.
All things being equal, if you’re doing the exact same work and have the same likelihood of leaving, would your employer prefer to pay you less or more?
Most employers will pay you less if they can, and I almost had to learn that the hard way.</p>
<p><strong>Applying the principle:</strong> In my story above, I never proactively negotiated.
Instead, I accepted a job offer from the financial company without any sort of additional demands.
If they were happy to offer me a 20% raise just to quit open source, I probably could have gotten an even higher salary if I’d just asked in the first place.</p>
<h4 id="negotiation-starts-early-and-never-ends">Negotiation starts early, and never ends</h4>
<p>Not only do you need to negotiate actively, you also need to realize that negotiation starts much earlier than you think, and ends only when you leave to a different job:</p>
<ul>
<li>The minute you start thinking about applying to a company, you’ve started the negotiation process; as you’ll see, you’ll want to do research before you even talk to them.</li>
<li>Your interview is part of your negotiation, and you can in fact negotiate the interview process itself (e.g. suggest sharing a code sample instead of doing a whiteboard puzzle).</li>
<li>As an employee you will continue to negotiate: if you always say “yes” when your boss asks you to work long hours, your contract for a 3-day weekend will mean nothing.</li>
</ul>
<p>In short, your whole relationship as an employee is based on negotiation.</p>
<h4 id="distinguish-between-friend-and-foe">Distinguish between friend and foe</h4>
<p>A negotiation involves two sides: yours, and the company’s.
When you’re negotiating it’s important to remember that anyone who works for the company is on the company’s side.
Not yours.</p>
<blockquote>
<p>I once had to negotiate the intellectual property agreement at a new job.
My new employer was based in the UK, and it had a US subsidiary organized by a specialist company.
These subsidiary specialists had provided the contract I was signing.</p>
<p>When I explained the changes I wanted to make, the manager at the subsidiary specialist told me that my complaint had no merit, because the contract had been written by the “best lawyers in Silicon Valley.”
But the contract had been written by lawyers working for the <em>company</em>, not for me.
If his claim had been true (spoiler: they were not in fact the best lawyers in Silicon Valley), that would have just made my argument stronger.
The better the company’s lawyers, the more carefully I ought to have read the contract, and the more I ought to have pushed back.</p>
</blockquote>
<p>The contracts the company wants you to sign?
They were written by lawyers working for the company.</p>
<p>Human Resources works for the company, as does the in-house recruiter.
However friendly they may seem, they are not working for you.
And third-party recruiters are paid by the company, not you.
It’s true that sometimes their commission is tied to your salary, which means they would rather you get paid more.
But since they get paid only once per candidate, volume is more important than individual transactions: it’s in their best interest to get you hired as quickly as possible so they can move on to placing the next candidate.</p>
<p>Since all these people aren’t working for you, during a negotiation they’re <em>working against you</em>.</p>
<p>The only potential exception to this rule are friends who also work for the company, and aren’t directly involved in the negotiation process: even if they are constrained in some ways, they’re probably still on your side.
They can serve as a backchannel for feedback and other information that the company can’t or won’t share.</p>
<h3 id="principle-2-knowledge-is-power">Principle #2: Knowledge is power</h3>
<p>The more you know about the situation, the better you’ll do as a negotiator.
More knowledge gives more power: to you, but also to the company.</p>
<h4 id="know-what-you-want">Know what you want</h4>
<p>The first thing you need to do when negotiating is understand what <em>you</em> want.</p>
<ul>
<li>What is your ideal outcome?</li>
<li>What can you compromise on, and what can’t you compromise on?</li>
<li>What is the worst outcome you’re willing to accept?</li>
</ul>
<h4 id="do-your-research">Do your research</h4>
<p>You also want to understand where the other side is coming from:</p>
<ul>
<li>What is the company’s goal, and the negotiator’s goal?
For example, if you discover their goal is minimizing hassle, you might be able to get what you want by making the process a little smoother.</li>
<li>What resources are available to them?
An unfunded startup has different resources than a large company, for example.</li>
<li>Has the company done something similar in the past, or will your request be unprecedented?
For example, what hours do other employees in similar positions work?
How much are other employees paid?</li>
<li>What do other companies in the area or industry provide?</li>
<li>How is this particular business segment doing: are they losing money, or doing great?</li>
</ul>
<p>The more you understand going in, the better you’ll do, and that means doing your research <em>before</em> negotiation starts.</p>
<p><strong>Applying the principle:</strong> In my story above I never did any research about salaries, either in NY or in Boston.
As a result, I had no idea I was being offered a salary far below market rates.</p>
<p>As a comparison, here’s a real example of how research can help your negotiation, from an engineer named Adam:</p>
<blockquote>
<p>Adam: “Being informed on salaries really helped my negotiating position.
When my latest employer made me an offer I asked them why it was lower than their average salary on Glassdoor.com.
The real reason was likely ‘we offer as little as possible to get you on board.’
They couldn’t come up with a convincing reason and so the salary was boosted 10%.”</p>
</blockquote>
<p>Glassdoor is a site that allows employees to anonymously share salaries and job reviews.
Five minutes of research got Adam a 10% raise: not bad at all!</p>
<h4 id="listen-and-empathize">Listen and empathize</h4>
<p>If you only had to make yourself happy this wouldn’t be a negotiation: you need to understand the other side’s needs and wants, what they’re worrying about, what they’re feeling.
That means you need to listen, not just talk: if you do, you will often gather useful information that can help you make yourself more valuable, or address a particular worry.
And you need to feel empathy towards the person you’re talking to: you don’t need to agree or subordinate yourself to their goals, but you do need to understand how they’re feeling.</p>
<h4 id="share-information-carefully">Share information carefully</h4>
<p>Sharing information at the wrong time during a negotiation can significantly weaken your position.
For example, sharing your previous salary will often anchor what the company is willing to offer you:</p>
<blockquote>
<p>Adam: “I graduated from university and started working at the end of 2012.
At my first job I worked for way under my market rate.
I knew this and was OK with it because they were a good company.</p>
<p>Then I switched jobs in 2013.
What I hadn’t accounted for was that my salary at my first job was going to limit my future salary prospects.
I had to fight hard for raises at my next job before I was in line with people straight out of school, because they didn’t want to double my salary at my previous company.”</p>
</blockquote>
<p>In general, when interviewing for a job you shouldn’t share your previous salary, or your specific salary demands—except of course when it <em>is</em> helpful to do so.
For example, let’s say you’re moving from Google to a tiny bootstrapped startup, and you know you won’t be able to get the same level of salary.
Sharing your current salary can help push your offer higher, or used as leverage to get shorter hours: “I know you can’t offer me my previous salary of $$$, but here’s something you could do—”.
Just make sure not to share it too early, or they might decide you’d never accept any offer at all and stop the interview process too early.</p>
<p>Most of the time, however, you shouldn’t share either your previous salary or specific salary requirements.
If the company insists on getting your previous salary, you can:</p>
<ul>
<li>If you work somewhere with relevant laws (e.g. California and Massachusetts), point out that this question is illegal.
Asking about salary <em>expectations</em> is not illegal in these jurisdictions, so be careful about the distinction.</li>
<li>Ask for the company’s salary range for the position, as well as the next level up in the salary tree.
Chances are they will refuse to share, in which case you can correspondingly refuse to share your information.</li>
<li>Say something like “I expect to be paid industry-standard pay for my experience.”</li>
</ul>
<p><strong>Applying the principle:</strong> I shouldn’t have told ITA Software my salary requirement.
Instead, I should have gotten them to make the first offer, which would have given me more information about what they were willing to pay.</p>
<h3 id="principle-3-negotiate-from-a-position-of-strength">Principle #3: Negotiate from a position of strength</h3>
<p>The stronger your negotiation position, the more likely you are to get what you want.
And this is especially important when you’re asking for something abnormal, like a 3-day weekend.</p>
<h4 id="have-a-good-fallback-batna">Have a good fallback (BATNA)</h4>
<p>If negotiation fails, what will you do?
Whatever it is, that is your fallback, sometimes known as the “Best Alternative to a Negotiated Agreement” (BATNA).
The better your fallback, the better your alternative, the stronger your negotiating position is.
Always figure out your fallback in advance, before you start negotiating.</p>
<p>For example, imagine you’re applying for a new job:</p>
<ul>
<li>If you’re unemployed and have an empty bank account, your fallback might be moving in with your parents.
This does not give you a strong negotiating position.</li>
<li>If you’re employed, and more or less content with your current job, your fallback is staying where you are.
That makes your position much stronger.</li>
</ul>
<p>If you have a strong fallback, you can choose to walk away at any time, and this will make asking for more much easier.</p>
<h4 id="provide-and-demonstrate-value">Provide and demonstrate value</h4>
<p>The more an organization wants you as an employee, the more they’ll be willing to offer you.
The people you’re negotiating with don’t necessarily know your value: you need to make sure they understand why you’re worth what you’re asking.</p>
<p>For example, when you’re interviewing for a job, you need to use at least part of the interview to explain your value to your prospective employer: your accomplishments and skills.
Once you’ve established the value of your skills, asking for more—more money, unusual terms—can actually make you seem more valuable.
And having another job offer—or an existing job—can also help, by showing you are in demand.</p>
<p>Finally, remember that your goal is to make sure the other side’s needs are met—not at your own expense, but if they don’t think hiring you is worth it, you aren’t going to get anything.
Here’s how Alex, another programmer I talked to, explains how he learned this:</p>
<blockquote>
<p>Alex: “Think about the other person and how they’re going to react, how you can try to manage that proactively.
You need to treat your negotiating partner as a person, not a program.</p>
<p>Initially I had been approaching it adversarially, ‘I need to extract value from you, I have to wrestle you for it’ but it’s more productive to negotiate with an attitude of ‘we both need to get our needs met.’
The person you’re talking to is looking to hire someone productive who can create value, so figure out how can you couch what you want in a way that proactively addresses the other person’s concerns.”</p>
</blockquote>
<h3 id="principle-4-use-the-right-tactics">Principle #4: Use the right tactics</h3>
<p>Once you’ve realized you’re negotiating, have done your research, and are negotiating from a position of strength, applying the right negotiation tactics will increase your chances of success even more.</p>
<h4 id="ask-for-more-than-you-want">Ask for more than you want</h4>
<p>Obviously you don’t want to ask for less than what you want.
But why not ask for exactly what you want?</p>
<p>First, it might turn out that the company is willing to give you far more than you expected or thought possible.</p>
<p>Second, if you ask for exactly what you want there’s no way for you to compromise without getting less than what you want.
By asking for more, you can compromise while still getting what you wanted.</p>
<p><strong>Applying the principle:</strong> If I’d wanted a $72,000 salary, and research suggested that was a fair salary, I should have asked for $80,000.
If I was lucky the company would have said yes; if they wanted to negotiate me down, I would have no problems agreeing to a lower number so long as it was above $72,000.</p>
<h4 id="negotiate-multiple-things-at-once">Negotiate multiple things at once</h4>
<p>Your goal when negotiating is not to “win.”
Rather, your goal is to reach an agreement that passes your minimal bar, and gets you as much as is feasible.
Feasibility means you also need to take into account what the other side wants as well.
If you’ve reached an impasse, and you still think you can make a deal that <em>you</em> like, try to come up with creative ways to work out a solution that <em>they</em> will like.</p>
<p>If you only negotiate one thing at once, every negotiation has a winner and a loser.
For example, if all you’re negotiating is salary, either you’re making more money, or the company is saving money: it’s a zero-sum negotiation.
This limits your ability to come up with a solution that maximizes value for you while still meeting the other side’s needs.</p>
<p><strong>Applying the principle:</strong> In my story above, the financial company wanted intellectual property protection, I wanted to be able to write open source, and we were at an impasse.
So they expanded the scope of the negotiation to include my salary, which allowed them to make tradeoffs between the two—more money for me in return for what they wanted.
If I’d cared less about working on open source I might have accepted that offer.</p>
<h4 id="never-give-an-answer-immediately">Never give an answer immediately</h4>
<p>During the actual negotiation you should never decide on the spot, nor are you required to.
If you get a job offer you can explain that you need a little time to think about it: say something like “I have to run this by my spouse/significant other/resident expert.”
This will give you the time to consider your options in a calmer state of mind, and not just blurt out “yes” at the first semi-decent offer.</p>
<p>Having someone else review the offer is a good idea in general; a friend of mine ran her job offers by her sister, who had an MBA.
But it’s also useful to mention that other person as someone who has to sign off on the offer.
That gives you the ability to say you’d like to accept an offer, but your spouse/expert thinks you can do better.</p>
<p>Notice that the employer almost always has this benefit already.
Unless you’re negotiating with the owner of the business, you’re negotiating with an agent: someone in HR, say.
When you make a demand, the HR person might say “I have go to check with the hiring manager”, and when they come back with less than you wanted it’s not <em>their</em> fault, they’re just passing on the bad news.
The implication is that the low offer is just the way it is, and there’s nothing they can do about.</p>
<p>Don’t fall for this trick: they often can change the offer.</p>
<h2 id="beyond-negotiating-for-salary">Beyond negotiating for salary</h2>
<p>You can negotiate for a higher salary—or rather, you <em>should</em> negotiate for a higher salary.
The Adam I interviewed in this article is now a partner in DangoorMendel, <a href="https://www.dangoormendel.com/">who can help you negotiate a higher salary</a>.</p>
<p>But salary isn’t the only thing you can negotiate for.
<strong>You can also negotiate for a shorter workweek.</strong></p>
<p>And yes, this is harder, but it’s definitely possible.</p>
<p>In fact, this article is an excerpt from a book I wrote to help you do just that: <a href="/3dayweekend/"><em>You Can Negotiate a 3-Day Weekend</em></a>.</p>
<br><hr>
<h3>Tired of scrambling to get your job done?<br><br>If you were productive enough, you could take the afternoon off, confident you’d produced high value work. Not to mention having an easier time finding a new job when you need one.<br><br>Learn the <a href="/secretskills/">secret skills of productive programmers</a>.</h3>
What can a software developer do about climate change?2019-09-10T00:00:00+00:00https://codewithoutrules.com/2019/09/10/software-developers-climage-change<p>Pines and firs are dying across the Pacific Northwest, fires rage across the Amazon, it’s the hottest it’s ever been in Paris—climate change is impacting the whole planet, and things are not getting any better.
<strong>You want to do something about climate change, but you’re not sure what.</strong></p>
<p>If you do some research you might encounter an essay by Bret Victor—<a href="http://worrydream.com/ClimateChange/">What can a technologist do about climate change?</a>
There’s a whole pile of good ideas in there, and it’s worth reading, but the short version is that you can use technology to “create options for policy-makers.”</p>
<p>Thing is, policy-makers aren’t doing very much.</p>
<p><strong>So this essay isn’t about technology, because technology isn’t the bottleneck right now, it’s about policy and politics what you can do about it.</strong>
It’s still written for software developers, because that’s who I write for, but also because software developers often have access to two critical catalysts for political change.
And it’s written for software developers in the US, because that’s where I live, and because the US is a big part of the problem.</p>
<p>But before I go into what you can do, let me tell you the story of a small success I happened to be involved in, a small step towards a better future.</p>
<!-- TEASER_END -->
<h2 id="infrastructure-and-the-status-quo">Infrastructure and the status quo</h2>
<p>About a year ago I spent some of my mornings handing out pamphlets to bicycle riders.
I looked like an idiot: in order to show I was one of them I wore my bike helmet, which is weirdly shaped and the color of fluorescent yellow snot.</p>
<p>After finding an intersection with plenty of bicycle riders and a long red light that forces them to stop, I would do the following:</p>
<ol>
<li>When the light turns red, step into the street and hand out the pamphlet.</li>
<li>Keep an eye out for the light changing to green so that I didn’t get run over by moving cars.</li>
<li>Twiddle my thumbs waiting for the next light cycle.</li>
</ol>
<p>It was boring, and not very glamorous.</p>
<p>I was one of just many volunteers, and besides gathering signatures we also held rallies, had conversations with city councilors and staff, wrote emails, talked at city council meetings—it was a process.
The total effort took a couple of years (and I only joined in towards the end)—but in the end we succeeded.</p>
<p><strong>We succeeded in having the council pass a short ordinance, a city-level law in the city of Cambridge, Massachusetts.</strong>
The ordinance states that whenever a road that was supposed to have protected bike lanes (per the city’s Bike Plan) was rebuilt from scratch, it would have those lanes built by default.</p>
<p>Now, clearly this ordinance isn’t going to solve climate change.
In fact, <em>nothing</em> Cambridge does as a city will solve climate change, because there’s only so much impact 100,000 people can have on greenhouse gas emissions.</p>
<p><strong>But while in some ways this ordinance was a tiny victory in a massive war, if we take a step back it’s actually more important than it seems.</strong>
In particular, this ordinance has three effects:</p>
<ol>
<li>Locally, safer bike infrastructure means more bicycle riders, and fewer car drivers. That reduces emissions—a little.</li>
<li>Over time, more bicycle riders can kick off a positive feedback cycle, reducing emissions even more.</li>
<li>Most significantly, local initiatives spread to other cities—kicking off these three effects in those other cities.</li>
</ol>
<p>Let’s examine these effects one by one.</p>
<h2 id="effect-1-fewer-cars-less-emissions">Effect #1: Fewer cars, less emissions</h2>
<p>About 43% of the greenhouse gas emissions in Massachusetts are due to transportation; for the US overall it’s 29% (<a href="https://www.mass.gov/service-details/ma-ghg-emission-trends">ref</a>).
And that means cars.</p>
<p><strong>The reason people in the US mostly drive cars is because all the transportation infrastructure is built for cars.</strong>
No bike lanes, infrequent, slow and non-existent buses, no trains…
Even in cities, where other means of transportation are feasible, the whole built infrastructure sends the very strong message that cars are the only reasonable way to get around.</p>
<p>If we focus on bicycles, our example at hand, the problem is that riding a bicycle can be dangerous—mostly because of all those cars!
But if you get rid of the danger and build good infrastructure—dedicated protected bike lanes that separate bicycle riders from those dangerous cars—then bicycle use goes up.</p>
<p>Consider what Copenhagen achieved between 2008 and 2017 (<a href="https://kk.sites.itera.dk/apps/kk_pub2/pdf/1962_fe6a68275526.pdf">ref</a>):</p>
<table>
<thead>
<tr>
<th> </th>
<th>2008</th>
<th>2018</th>
</tr>
</thead>
<tbody>
<tr>
<td># of seriously injured cyclists</td>
<td>121</td>
<td>81</td>
</tr>
<tr>
<td>% who residents who feel secure cycling</td>
<td>51</td>
<td>77</td>
</tr>
<tr>
<td>% who cycle to work/school</td>
<td>37</td>
<td>49</td>
</tr>
</tbody>
</table>
<p><strong>With safer infrastructure for bicycles, perception of safety goes up, and people bike more and drive less.</strong>
Similarly, if you have frequent, fast, and reliable buses and trains, people drive less.
And that means less carbon emissions.</p>
<p>In Copenhagen the number of kilometers driven by cars was flat or slightly down over those 10 years—whereas in the US, it’s up 6-7% (<a href="https://fred.stlouisfed.org/series/M12MTVUSM227NFWA">ref</a>).</p>
<h2 id="effect-2-a-positive-feedback-loop">Effect #2: A positive feedback loop</h2>
<p>The changes in Copenhagen are a result of a plan the city government there adopted in 2011 (<a href="https://en.wikipedia.org/wiki/Cycling_in_Copenhagen#Current_bicycle_strategy_(2011%E2%80%932025)">ref</a>): they’re the result of a policy action.
And the political will was there in part because there were <em>already</em> a huge number of bicycle riders.
So it’s a positive feedback loop, and a good one.</p>
<p>Let’s see how this is happening in Cambridge:</p>
<ul>
<li>Cambridge has a slowly growing number of bicycle rider.
This means more political support for bike infrastructure—if there’s a group that can mobilize that support!</li>
<li>With the ordinance, more roads will have safe infrastructure.
For example, one neighborhood previously had a safe route only in one direction; the other direction will be rebuilt with a protected bike lane in 2020.</li>
<li>With safer infrastructure, there will be more bicycle riders, and therefore more support by residents for safer infrastructure.
Merely having support isn’t enough, of course, and I’ll get back to that later on.</li>
</ul>
<p>If Copenhagen can reach 50% of residents with a bicycle commute, so can Cambridge—and the ordinance is a good step in that direction.</p>
<h2 id="effect-3-the-idea-spreads">Effect #3: The idea spreads</h2>
<p>The Cambridge ordinance passed in April 2019—and the idea is spreading elsewhere:</p>
<ul>
<li>The California State Assembly is voting on a law with similar provisions (<a href="https://www.calbike.org/our_initiatives/streets_for_everyone/complete_streets/">ref</a>), through a parallel push by Calbike.</li>
<li>In May 2019 a Washington DC Council member introduced a bill which among other points has the same rebuild requirements as the Cambridge ordinance (<a href="https://usa.streetsblog.org/2019/05/08/d-c-bill-would-make-protected-bike-lanes-mandatory/">ref</a>).</li>
<li>The Seattle City Council passed an ordinance, parts of which were literally copy/pasted from the Cambridge ordinance (<a href="https://www.seattletimes.com/seattle-news/transportation/seattle-city-council-approves-new-bike-lane-requirements-calls-for-more-bike-lane-funding/">ref</a>).</li>
</ul>
<p>All of this is the result of local advocacy—but I’ve no doubt Cambridge’s example helped.
It’s always easier to be the second adopter.
And the examples from these larger localities will no doubt inspire other groups and cities, spreading the idea even more.</p>
<h2 id="change-requires-politics">Change requires politics</h2>
<p>Bike infrastructure is just an example, not a solution—but there are three takeaways from this story that I’d like to emphasize:</p>
<ul>
<li>If you want to change policy, you need to engage in politics.</li>
<li>Politics are easier to impact on the local level.</li>
<li>Local policy changes have a cumulative, larger-scale impact.</li>
</ul>
<p>By politics I don’t just mean having an opinion or voting for a candidate, but rather engaging in the process of how policy decisions are made.</p>
<p><strong>Merely having an opinion doesn’t change anything.</strong>
For example, two-thirds of Cambridge residents support building more protected bike lanes (<a href="https://www.cambridgebikesafety.org/2019/03/19/two-thirds-cambridge-residents-protected-want-protected-bike-lanes/">ref</a>).
But that doesn’t mean that many protected lanes are getting built—the neighboring much smaller city of Somerville is building far more than Cambridge.</p>
<p>The only reason the city polled residents about bike lanes is because, one suspects, all the fuss we’d been making—emails, rallies, meetings, city council policy orders—made the city staff wonder if bike infrastructure really had a lot of public support or not.</p>
<p><strong>Voting results in some change, but not enough.</strong>
Elected officials and government staff have lots and lots of things to worry about—if they’re not being pressured to focus on a particular issue, it’s likely to fall behind.</p>
<p>What’s more, the candidates you get to vote for have to get on the ballot, and to do that they need money (for advertising, hiring staff, buying supplies).
Lacking money, they need volunteer time.</p>
<p>And it’s much easier for a small group of rich people to provide that support to the candidates <em>they</em> want—so by the time you’re voting, you only get to choose between candidates that have been pre-vetted (I highly recommend reading <em><a href="https://www.press.uchicago.edu/ucp/books/book/chicago/G/bo3624792.html">The Golden Rule</a></em> to understand how this works on a national level).</p>
<h2 id="what-you-can-do-become-an-activist">What you can do: Become an activist</h2>
<p><strong>In the end power is social.</strong>
Power comes from people showing up to meetings, people showing up for rallies, people going door-to-door convincing other people to vote for the right person or support the right initiative, people blocking roads and making a fuss.</p>
<p>And that takes time and money.</p>
<p>So if you want to change policy, you need to engage in politics, with time and money:</p>
<ul>
<li>You can volunteer for candidates’ political campaigns, as early as possible in the process.
Too many good candidates get filtered out before they even make the ballot.
That doesn’t mean you can just go home after the election—that’s when the real work of legislation starts, which means activism is just as important.</li>
<li>You can volunteer with groups either acting on a particular issue (transportation, housing policy) or more broadly on climate change.</li>
<li>Also useful is donating money to political campaigns, both candidates and issue-based organizations.</li>
</ul>
<p>Here are some policies you might be interested in:</p>
<ul>
<li>Transportation policy determines what infrastructure is built—and the current infrastructure favors privately-owned cars over public transportation and bicycles.</li>
<li>Zoning laws determine what gets built and where.
Denser construction would reduce the need for long trips, and more efficient buildings (ideally net zero carbon) would reduce emissions from heating and cooling.</li>
<li>Moving utilities from private to public ownership, so they can focus on the public good and not on profit.</li>
<li>Bulk municipal contracts for electricity: this allows for cheaper electricity for all residents, and to have green energy as the default.</li>
<li>State-level carbon restrictions or taxes.</li>
</ul>
<h2 id="where-you-should-do-it-start-local">Where you should do it: Start local</h2>
<p>If you are going to become an activist, the local level is a good starting point.</p>
<ul>
<li><strong>An easier first step:</strong> Cambridge has 100,000 residents—city councilors are routinely elected with just 2500 votes.
That means impacting policies here is much easier than at a larger scale.
Not only does this mean faster results, it also means you’re less likely to get discouraged and give up—you can see the change happening.</li>
<li><strong>Direct impact:</strong> A significant amount of greenhouse gas emissions in the US are due to causes that are under control of local governments.</li>
<li><strong>Wider impact:</strong> As in the case of Cambridge’s ordinance, local changes can be adopted elsewhere.</li>
</ul>
<p>Of course, local organizing is just the starting point for creating change on the global level.
But you have to start somewhere.
And global change is a lot easier if you have thousands of local organizations supporting it.</p>
<h2 id="its-a-good-to-be-a-software-developer">It’s a good to be a software developer</h2>
<p><strong>Let’s get back to our starting point—you’re paid to write software, you want to do something about climate change.</strong>
As a software developer you likely have access to the inputs needed to make political campaigns succeed—both candidate-based and issue-based:</p>
<ul>
<li><strong>Money:</strong> Software developers tend to get paid pretty well, certainly better than most Americans.
Chances are you have some money to spare for political donations.</li>
<li><strong>Time:</strong> This one is a bit more controversial, but in my experience many programmers can get more free time if they want to.</li>
</ul>
<p><strong>If you don’t have children or other responsibilities, you can work a 40-hour workweek, leaving you time for other things.</strong>
Before I got married I worked full-time and went to a local adult education college half-time in the evenings: it was a lot of work, but it was totally doable.
<a href="/2019/04/03/setting-boundaries-at-work/">Set boundaries at your job</a>, and you’ll have at least some free time for activism.</p>
<p><strong>You can also negotiate a shorter workweek, which is possible in part because software developers are in such demand.</strong>
I’ve done this, I’ve <a href="/2018/01/08/part-time-programmer/">interviewed people who have done it</a>, I’ve found <a href="/2019/05/09/part-time-software-developer/">many random people on the Internet who have done it</a>—it is possible.</p>
<p>If you need help doing it yourself, I’ve written <a href="/3dayweekend/">a book to help you negotiate a shorter workweek</a>.
<strong>If you want to negotiate a shorter workweek so you have time for political activism, you can use the code <code class="language-plaintext highlighter-rouge">FIGHTCLIMATECHANGE</code> to <a href="/3dayweekend/">get the book</a> for 60% off.</strong></p>
<h2 id="some-common-responses">Some common responses</h2>
<h3 id="there-will-never-be-the-political-will-to-make-this-happen">“There will never be the political will to make this happen”</h3>
<p>Things do change, for better and for worse, and sometimes unexpectedly.
To give a couple of examples:</p>
<ul>
<li>In Ireland, the Catholic Church went from all-powerful to losing badly, most recently with Ireland legalizing abortion.</li>
<li>The anti-gay-marriage <em>Defense of Marriage Act</em> was passed by veto-proof majorities of Congress in 1996—and eight years later in 2004 the first legal gay marriage took place right here in Cambridge, MA.</li>
</ul>
<p>The timelines for <a href="https://en.wikipedia.org/wiki/Timeline_of_same-sex_marriage_in_the_United_States">gay marriage</a> and <a href="https://en.wikipedia.org/wiki/Timeline_of_cannabis_laws_in_the_United_States">cannabis legalization</a> in the US are illuminating: these things didn’t just happen, it was the result of long, sustained activist efforts, much of it at the local level.</p>
<p>Local changes do make a difference.</p>
<h3 id="politics-is-awful-and-broken">“Politics is awful and broken”</h3>
<p>So are all our software tools, and somehow we manage to get things done!</p>
<h3 id="i-dont-like-your-policy-suggestions-we-should-do-x-instead">“I don’t like your policy suggestions, we should do X instead”</h3>
<p>No problem, find the local groups that promote your favorite policies and join them.</p>
<h3 id="the-necessary-policies-will-never-work-because-of-problem-y">“The necessary policies will never work because of problem Y”</h3>
<p>Same answer: join and help the local groups working on Y.</p>
<h3 id="its-too-late-the-planet-is-doomed-no-matter-what-we-do">“It’s too late, the planet is doomed no matter what we do”</h3>
<p>Perhaps, but it’s very hard to say.
So we’re in Pascal’s Wager territory here: given even a tiny chance there is something we can do, we had better do our best to make it happen.</p>
<p>And even if humanity really is doomed, there’s always the hope that someday a hyperintelligent species of cockroach will inherit the Earth.
And when cockroach archaeologists try to reconstruct our history, I would like them to be able to say, loosely translated from their complex pheromone-and-dancing system of communication: “These meatsacks may not have been as good at surviving as us cockroaches—but at least they tried!”</p>
<h2 id="time-to-get-started">Time to get started</h2>
<p>If you find this argument compelling—that policy is driven by power, and that power requires social mobilization—then it’s up to you to take the next step.
Find a local group or candidate pushing for a policy you care about, and show up for the next meeting.</p>
<p>And the meeting after that.</p>
<p>And then go to the rally.</p>
<p>And knock on doors.</p>
<p>And make some friends, and make some changes happen.</p>
<p>Some of the work is fun, some of it is boring, but there’s plenty to do—time to get started!</p>
<br><hr>
<h3>Tired of scrambling to get your job done?<br><br>If you were productive enough, you could take the afternoon off, confident you’d produced high value work. Not to mention having an easier time finding a new job when you need one.<br><br>Learn the <a href="/secretskills/">secret skills of productive programmers</a>.</h3>
Learning negotiation from Jane Austen2019-05-15T00:00:00+00:00https://codewithoutrules.com/2019/05/15/jane-austen-negotiating-guide<p>Looking for a job as a software developer can be scary, exhausting, or overwhelming.
Where you apply and how you interview impacts whether you’ll get a job offer, and how good it will be, so in some sense the whole job search is a form of negotiation.</p>
<p>So how do you learn to make a good impression, to convince people of your worth, to get picked by the job you want?
There are many skills to learn, and in this article I’d like to cover one particular subset.</p>
<p>Let us travel to England, some 200 years in the past, and see what we can learn.</p>
<!-- TEASER_END -->
<h2 id="jane-austen-game-theorist">Jane Austen, Game Theorist</h2>
<p>What does a novelist writing in the early 19th century have to do with getting a programming job?</p>
<p>In his book <a href="https://press.princeton.edu/titles/10031.html"><em>Jane Austen, Game Theorist</em></a>, Michael Suk-Young Chwe argues quite convincingly that Austen’s goal in writing her books is to teach <em>strategic thinking</em>: understanding what and why people do what they do, and how to interact with them accordingly, in order to achieve the outcomes <em>you</em> want.</p>
<p><strong>Strategic thinking is a core skill in negotiation: you’re trying to understand what the other side wants (even if they don’t explicitly say it), and to find a way to use that to get what you want.</strong>
The hiring manager might want someone who both understands their particular technical domain and can help a team grow, whereas you might want a higher salary, or a shorter workweek.
Strategic thinking can help you use the one to achieve the other.</p>
<p>Strategic thinking is of course a useful skill for anyone, but why would Jane Austen in particular care about strategic thinking?
To answer that we need a little historical context.</p>
<h2 id="the-worst-job-search-ever">The worst job search ever</h2>
<p><strong>Imagine you could only get one job your whole life, that leaving your job was impossible, and that you’d be married to your boss.</strong>
This is the “job search” that Austen faced in her own life, and is one the main topics covered in her books.</p>
<p>Austen’s own family, and the people she writes about, were part of a very small and elite minority.
Even the poorest of the families Austen writes about have at least one servant, for example.</p>
<p>While the men of the English upper classes, if they were not sufficiently wealthy, could and did work—as lawyers, doctors, officers—their wives and daughters for the most part could not.
So if they weren’t married and didn’t have sufficient wealth of their own, upper-class women had very few choices—they could live off money from relations, or take on the social status loss of becoming a governess.</p>
<p><strong>Marriage was therefore the presumed path to social status, economic security, and of course it determined who they would live with for the rest of their lives (divorce was basically impossible).</strong></p>
<p>Finding the right husband was very important.
And getting that husband—who had all the legal and social authority—to respect their wishes after marriage was just as important.
And of course the women who didn’t marry lived at the mercy of the family members who supported them.</p>
<p>And that’s where strategic thinking comes in: it was a critical skill for women in Austen’s class and circumstances.</p>
<h2 id="learning-from-austen">Learning from Austen</h2>
<p>If, as Michael Chwe argues, Austin’s goal with her books is to teach strategic thinking, how can you use them to improve your negotiation skills?</p>
<p><strong>All of Austen’s books are worth reading—excepting the unfortunate <em>Mansfield Park</em>—but for educational purposes <em>Northanger Abbey</em> is a good starting point.</strong>
<em>Northanger Abbey</em> is the story of Catherine, a naive young woman, and how she becomes less naive and more strategic.</p>
<p>Instead of just reading it as an entertaining novel, you can use it to actively practice your own strategic understanding:</p>
<ol>
<li>In every social interaction, Catherine has a theory about other people’s motivations, why they’re doing or saying certain things.</li>
<li>Notice the assumptions underlying her theory, and then come up with your alternative theory or explanation for other characters’ actions.</li>
<li>Then, compare both theories as the plot unfolds and you learn more.</li>
</ol>
<p>Other characters also offer a variety of opportunities to see strategic thinking—or lack of it—in action.
<strong>Once you’ve gone through the book and experienced the growth of Catherine’s strategic thinking, start practicing those skills in your life.</strong></p>
<p>Why are your coworkers, family, and friends doing what they’re doing?
Do they have the same motivations, goals, and expectations that you do?
The more you pay attention and compare your assumptions to reality, the more you’ll learn—and the better you’ll do at your next job interview.</p>
<p>Ready to get started? You can get a paper copy from the library, or <a href="https://www.gutenberg.org/ebooks/121">download a free ebook</a>
from Project Gutenberg.</p>
<br><hr>
<h3>Tired of scrambling to get your job done?<br><br>If you were productive enough, you could take the afternoon off, confident you’d produced high value work. Not to mention having an easier time finding a new job when you need one.<br><br>Learn the <a href="/secretskills/">secret skills of productive programmers</a>.</h3>
Part-time software developer jobs don't exist, right?2019-05-09T00:00:00+00:00https://codewithoutrules.com/2019/05/09/part-time-software-developer<p>If you’re tired of working long hours, a part-time—or even just 4 days a week—programming jobs seems appealing.
You’ll still get paid, you’ll still hopefully enjoy your job—but you’ll also have more time for other things in your life.</p>
<p>Hypothetically you could negotiate for more free time, but obviously no company would ever agree to a shorter workweek, right?</p>
<p>And indeed there are plenty of people—on Hacker News especially—who will explain to you in great detail why this can’t be done, that no manager would ever agree to this, that it’s a logical impossibility, a mirage, a delusion, not even worth considering.</p>
<p>But—</p>
<p><strong>The fact is there are quite a few software developers who work less than full-time.</strong>
And to help convince you, I figured I would share just a few of the examples I know of.</p>
<!-- TEASER_END -->
<h2 id="ive-done-it">I’ve done it</h2>
<p>Personally I’ve worked at three different software jobs at between 28 and 35 hours a week.
And before that, when I left my last full-time job, my manager offered to help me find a part-time job there so that I would stay.</p>
<h2 id="people-who-have-read-my-book-have-done-it">People who have read my book have done it</h2>
<p>Since I appreciated having a shorter workweek so much, I ended up <a href="/3dayweekend/">writing a book about negotiating a 3-day weekend</a>, and a number of people who read my book have successfully done so.</p>
<p>I could share quotes from people who did it, and the sales page above includes just some of them, but you might feel that lacks a little credibility.
So let’s move on—</p>
<h2 id="people-ive-interviewed-have-done-it">People I’ve interviewed have done it</h2>
<p>I also interviewed a number of people for the book, including a guy by the name of Mike who has been working 4 days a week for 15 years now.
You can read <a href="/2018/01/08/part-time-programmer/">the full interview with Mike</a> if you want to get his perspective.</p>
<p>But he’s just one person, so let’s move on to the final category: random people on the Internet.</p>
<h2 id="random-people-on-the-internet-have-done-it">Random people on the Internet have done it</h2>
<p>Here’s just a sample:</p>
<p><a href="https://lobste.rs/s/hvjwd6/how_become_part_time_programmer#c_cz4dkd">pushcx on lobste.rs</a>: “I’ve worked part-time for about six years of my career.”</p>
<p><a href="https://lobste.rs/s/hvjwd6/how_become_part_time_programmer#c_v0itbn">Seitsebb on lobste.rs</a>: “I work four days a week and can recommend it.”</p>
<p><a href="https://lobste.rs/s/qchipn/less_stress_more_productivity_why#c_kxwsdf">stsp on lobste.rs</a>: “I was fortunate enough to be able to negotiate [Fridays off] while employed and it had a very positive impact on both my work and quality of life in general.”</p>
<p><a href="https://dev.to/acflint/comment/987f">acflint on dev.to</a>: “I negotiated a 4 day weekend so I could spend time on my side project … and enjoy life more.”</p>
<p><a href="https://news.ycombinator.com/item?id=4779399#4781904">autarch on Hacker News</a>: “As part of my negotiations for my current job, I negotiated a 4-day (32 hour) work week. I take Fridays off and do my own projects and volunteer work.”</p>
<p><a href="https://news.ycombinator.com/item?id=9506339">Boycy on Hacker News</a>: “I asked my then employer if I could drop to 4 days a week, pro-rata, and was surprised when the answer was yes!”</p>
<p><a href="https://news.ycombinator.com/item?id=9506602">notacoward on Hacker News</a>: “When I reduced my hours, I was amused to notice that everyone from the VP who approved it down to the person in HR who handled the paperwork said they wished they could do the same. I told them all that they could.”</p>
<p><a href="https://news.ycombinator.com/item?id=18839293">lubonay on Hacker News</a>: “I worked on a 4-day week for about a year between 2017 and 2018 for a small consultancy company.”</p>
<p><a href="https://news.ycombinator.com/item?id=18840069">duckworthd on Hacker News</a>: “I’ve been working a 4 day/week schedule for 1.5 years now.”</p>
<p>I could go on, but no doubt this is getting repetitive.</p>
<h2 id="you-can-do-it-too">You can do it too</h2>
<p>Want to join us and get more time for yourself?</p>
<p>For most programmers, the easiest place to negotiate a 3-day weekend is <a href="/2019/01/25/4-day-workweek-easy-way/">at your current job</a>.</p>
<br><hr>
<h3>Tired of scrambling to get your job done?<br><br>If you were productive enough, you could take the afternoon off, confident you’d produced high value work. Not to mention having an easier time finding a new job when you need one.<br><br>Learn the <a href="/secretskills/">secret skills of productive programmers</a>.</h3>