# Itamar Turner-Trauring Helping you become a productive programmer and get work/life balance This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## From YAGNI to YDNIY DevFeed: [From YAGNI to YDNIY]() Original publisher: [Read original article]() Author: Itamar Turner-Trauring Published: 2020-09-18T00:00:00Z Content type: tutorial Language: en Sources: [Itamar Turner-Trauring]() Topics: [Python](), [Conda](), [jupyter](), [Linux](), [macOS](), [pip](), [data](), [C++]() Tags: [c-plus-plus](), [conda](), [jupyter](), [jupyter-notebooks](), [linux](), [macos](), [python](), [releases]() ### AI overview The article introduces YDNIY, or "You Don't Need It Yet," as a complement to YAGNI. It argues that features that are necessary but not release blockers can be delayed when a product remains useful without them. The author illustrates this with the staged development of the Python memory profiler Fil across Linux, macOS, Jupyter, Conda, and multiple memory-allocation APIs. ### Source excerpt 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. 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. 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. A real world example: shipping a new memory profiler In March 2020 I shipped the initial release of a new memory profiler for Python, Fil. Here's how it changed over time in terms of features, from May to August 2020: 0.3.0, initial release: Installable via pip packaging tool, runs only on Linux, only profiles complete program runs. 0.3.3: Support for an additional memory allocation API. 0.4.0: Support for out-of-memory situations. 0.5.0: macOS support. 0.6.0: Support for mmap() allocation API. 0.7.0: Support for C++ memory allocation API. 0.9.0: Much faster and lower overhead in some use cases, added support for yet another memory allocation API. 0.10.0: Support for running inside Jupyter notebooks, and native support for installing via the Conda packaging tool. 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. 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. 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 ## Find that bug! Using a search engine as a programmer DevFeed: [Find that bug! Using a search engine as a programmer]() Original publisher: [Read original article]() Author: Itamar Turner-Trauring Published: 2020-08-17T00:00:00Z Content type: tutorial Language: en Sources: [Itamar Turner-Trauring]() Topics: [Programming](), [issue tracker](), [Python](), [Stack Overflow](), [pandas](), [Logging](), [GitHub](), [JSON]() Tags: [bug](), [documentation](), [github](), [issue-tracker](), [json](), [pandas](), [python](), [search]() ### AI overview This article explains how programmers can find solutions to bugs and programming problems by searching project-specific issue trackers, documentation, Stack Overflow, and other local resources alongside general search engines. It uses an Eliot and Pandas error as an example of a GitHub issue that a general search engine did not index. ### Source excerpt 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. All you have to do is find this information. 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. No need to give up, though: there are still plenty of ways you can productively keep searching. Use site-specific search too 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. So instead of just using a search engine, use the local search engine of the project issue tracker, the documentation, StackOverflow, and so on. For example, let's saying you're using Eliot, 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: eliot dataframe is not json serializable. 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. 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. Local search engines often have the additional benefit of allowing more structured search, for example: An issue tracker might let you search by open/closed status, labels, or the affected version. StackOverflow questions are tagged with parti ## Your dev environment matters less than you think DevFeed: [Your dev environment matters less than you think]() Original publisher: [Read original article]() Author: Itamar Turner-Trauring Published: 2020-06-25T00:00:00Z Content type: opinion Language: en Sources: [Itamar Turner-Trauring]() Topics: [Development](), [toolchain](), [Programming](), [Tool]() Tags: [dev](), [development](), [programming](), [techniques](), [tool](), [toolchain]() ### AI overview This opinion article argues that developers should not overfocus on choosing the ideal development environment. Beginners should select tools that are popular, easy to start with, and good enough, then refine their choices as they gain experience and understand their working preferences. ### Source excerpt 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 their list is The Right Way To Do Things. So which do you choose? The short answer: it doesn't matter. Your choice of dev environment is meaningless. 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. 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. Learning how to cook 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. 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. The people eating the food you cook don't care about which knife you used: they care how the food tastes and looks. 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. But remember: the people eating your food still won't care which knife you used. Choosing a dev environment 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. And that applies just as much to the users of your code: they don't care which tools you used. And when you're starting out, whether programming in general or a new language or framework, you d ## To get a better programming job, explain your problem-solving skills DevFeed: [To get a better programming job, explain your problem-solving skills]() Original publisher: [Read original article]() Author: Itamar Turner-Trauring Published: 2020-05-18T00:00:00Z Content type: tutorial Language: en Sources: [Itamar Turner-Trauring]() Topics: [Programming](), [coding](), [Kubernetes]() Tags: [career](), [interviews](), [jobs](), [kubernetes](), [programming](), [skills]() ### AI overview The article explains how software job candidates can communicate problem-solving ability instead of only listing technologies. It presents three levels--Finders, Solvers, and Implementers--and recommends using precise language and examples in resumes and interviews to show the level of contribution. ### Source excerpt 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. If you can convey your level of skill at problem solving, you can get: More job offers. Jobs with technologies you don't know. A higher salary by getting slotted into a higher pay grade. Often just a few extra words can make a big difference in demonstrating your skills. Let's see how you can do it. Three levels of problem solving skills As I discussed elsewhere in more detail, problem solving comes in three stages, each approximately corresponding to a particular career stage (these names are due to Randall Koutnik): Staff or principal software engineers are Finders: they find new problems. Senior software engineers are Solvers: they solve already-identified problems. Junior software engineers are Implementers: they implement already-identified solutions. The earlier you are in the problem-solving process, the more productive you are, and therefore the more valuable as an employee. As a result, you need to communicate how advanced your skill is across these three levels to demonstrate your productivity. Everything from your resume to the stories you tell in interviews should communicate your level of skill. Explaining your skill level 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. Consider the following entry from a resume: Moved deployment from manually-managed hosts to a new Kubernetes cluster. This experience entry uses an implementation-level verb: "moved". Similarly, "coded", "tested", "wrote", "fixed", "optimized"--these are all about implementation. And maybe it's impl ## How to prepare for losing your programming job DevFeed: [How to prepare for losing your programming job]() Original publisher: [Read original article]() Author: Itamar Turner-Trauring Published: 2020-05-14T00:00:00Z Content type: opinion Language: en Sources: [Itamar Turner-Trauring]() Topics: [Programming]() Tags: [financial](), [how-to](), [job](), [programming]() ### AI overview This advice article explains how programmers can prepare for potential job loss by building financial reserves, reducing expenses, maintaining a professional network, keeping skills current, demonstrating those skills publicly, and developing fallback plans. ### Source excerpt 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. 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? 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: Try to make sure you have the necessary financial resources. 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. Come up with a series of fallback plans if things don't go well. Let's go over these one-by-one. Money in the bank 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 If you have at least six months of living expenses in cash, that's a good start. If not, it's best to think about how to get there. There are two sides to this: 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 this more detailed article. Ensuring your financial assets, if you have any, aren't correlated with your job. 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. 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. More broadly, if you own stocks and to a lesser extent corporate bonds, how correlated are they with your ability to keep a job? Even more broadly, how much of your net worth is tied to the te ## Productivity skills for programmers DevFeed: [Productivity skills for programmers]() Original publisher: [Read original article]() Author: Itamar Turner-Trauring Published: 2020-04-20T00:00:00Z Content type: article Language: en Sources: [Itamar Turner-Trauring]() Topics: [Code](), [coding](), [Software]() Tags: [article](), [code](), [skills](), [software](), [writing-code]() ### AI overview The article explains that programmers cannot complete every task and should prioritize valuable, high-leverage work. It argues that increasing working hours has diminishing returns and that productivity should be measured by useful problem-solving outcomes rather than lines of code. ### Source excerpt 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. 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. Faced with an ever growing list of tasks, how do you get everything done? The short answer is, you can't. You will never get everything done. What you can do, though, is choose the right work, the most valuable work, the most useful work, the work with most leverage. Choose the right work and you can gets orders of magnitude improvement in your output. Let's see how. The goal: increased output Your output as a programmer is based both on your productivity and on how much time you work: Output = Productivity x Time Worked 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. If you never slept, ate, or did anything but work--and this will literally kill you--you can work 4.2x 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. What is output for a programmer? 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: Productivity = Output per week If you're going to improve your productivity, you need to understand how to measure output. The obvious measure is how much code you write: the more code, the better. This measure is obvious, popular, ## Job negotiation for programmers: the basic principles DevFeed: [Job negotiation for programmers: the basic principles]() Original publisher: [Read original article]() Author: Itamar Turner-Trauring Published: 2019-11-27T00:00:00Z Content type: opinion Language: en Sources: [Itamar Turner-Trauring]() Topics: [Development](), [Open Source]() Tags: [article](), [career](), [intellectual-property](), [job](), [legal](), [open-source]() ### AI overview An article about negotiating salary, benefits, and work arrangements when starting a programming job. It presents four principles--viewing employment as a negotiated relationship, gathering knowledge, negotiating from a position of strength, and using appropriate tactics--and illustrates them with a story involving salary and intellectual-property terms affecting open-source work. ### Source excerpt 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?" Here's the thing: that final conversation about salary might be the most nerve-wracking part, but the negotiation process starts much much earlier. Which means you can enter that final conversation having positioned yourself for success--and feeling less stressed about it too. 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. In particular, I'll be talking about: An example from early in my career when I negotiated very very badly. The right way to negotiate, based on four principles: Employment is a negotiated relationship. Knowledge is power. Negotiate from a position of strength. Use the right tactics. The wrong way to negotiate Before moving on to the principles of negotiation, let me share a story of how I negotiated badly. 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. 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 agr ## What can a software developer do about climate change? DevFeed: [What can a software developer do about climate change?]() Original publisher: [Read original article]() Author: Itamar Turner-Trauring Published: 2019-09-10T00:00:00Z Content type: opinion Language: en Sources: [Itamar Turner-Trauring]() Topics: [Software]() Tags: [developer](), [infrastructure](), [policy](), [software](), [software-developer](), [us]() ### AI overview This opinion essay considers what software developers in the United States can do about climate change. It argues that policy and politics, rather than technology, are currently the main bottleneck, and describes the author's involvement in a successful campaign for protected bike-lane requirements in Cambridge, Massachusetts. ### Source excerpt 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. You want to do something about climate change, but you're not sure what. If you do some research you might encounter an essay by Bret Victor--What can a technologist do about climate change? 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." Thing is, policy-makers aren't doing very much. 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. 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. 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. Infrastructure and the status quo 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. After finding an intersection with plenty of bicycle riders and a long red light that forces them to stop, I would do the following: When the light turns red, step into the street and hand out the pamphlet. Keep an eye out for the light changing to green so that I didn't get run over by moving cars. Twiddle my thumbs waiting for the next light cycle. It was boring, and not very glamorous. I was one of just many volunteers, and besides gathering signatures we also held rallies, had conversations with city counci ## Learning negotiation from Jane Austen DevFeed: [Learning negotiation from Jane Austen]() Original publisher: [Read original article]() Author: Itamar Turner-Trauring Published: 2019-05-15T00:00:00Z Content type: tutorial Language: en Sources: [Itamar Turner-Trauring]() Topics: [Learning](), [Programming]() Tags: [article](), [developer](), [learning](), [programming](), [software-developer]() ### AI overview This article applies ideas about strategic thinking from Jane Austen's works and Michael Suk-Young Chwe's book Jane Austen, Game Theorist to negotiation during a software developer job search. It explains how understanding what hiring managers and candidates want can help both sides pursue their goals. ### Source excerpt 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. 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. Let us travel to England, some 200 years in the past, and see what we can learn. Jane Austen, Game Theorist What does a novelist writing in the early 19th century have to do with getting a programming job? In his book Jane Austen, Game Theorist, Michael Suk-Young Chwe argues quite convincingly that Austen's goal in writing her books is to teach strategic thinking: understanding what and why people do what they do, and how to interact with them accordingly, in order to achieve the outcomes you want. 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. 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. 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. The worst job search ever 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. This is the "job search" that Austen faced in her own life, and is one the main topics covered in her books. 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 wri ## Part-time software development jobs are possible DevFeed: [Part-time software development jobs are possible]() Original publisher: [Read original article]() Author: Itamar Turner-Trauring Published: 2019-05-09T00:00:00Z Content type: opinion Language: en Sources: [Itamar Turner-Trauring]() Topics: [Programming](), [Development](), [Software]() Tags: [career](), [developer](), [job](), [programming](), [software-developer]() ### AI overview The article argues that part-time software development work is possible, challenging the belief that companies will not agree to shorter workweeks. It supports this with the author's experience, examples from people who read the author's book, an interview subject, and online accounts. ### Source excerpt 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. Hypothetically you could negotiate for more free time, but obviously no company would ever agree to a shorter workweek, right? 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. But-- The fact is there are quite a few software developers who work less than full-time. And to help convince you, I figured I would share just a few of the examples I know of. I've done it 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. People who have read my book have done it Since I appreciated having a shorter workweek so much, I ended up writing a book about negotiating a 3-day weekend, and a number of people who read my book have successfully done so. 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-- People I've interviewed have done it 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 the full interview with Mike if you want to get his perspective. But he's just one person, so let's move on to the final category: random people on the Internet. Random people on the Internet have done it Here's just a sample: pushcx on lobste.rs: "I've worked part-time for about six years of my career." Seitsebb on lobste.rs: "I work four days a week and can recommend it." stsp on lo