Work/Life balance is bullshit

english

By Tobias van Schneider

Баланс работы и жизни — полная чушь

russian

Перевод manka

There is no question being asked more often than how I manage my work/life balance. Every time someone asks me that question I struggle with a straight answer.

У меня больше не спрашивают, как я управляю своим балансом жизни/работы. Каждый раз, когда я слышу такой вопрос, у меня появляется только один ответ.

For me the concept of work/life balance is bullshit. The fact that we call it work/life balance automatically implies that one of the two is negative and we need to balance it with the other.

Для меня, концепция баланса жизни/работы — полная чушь. Сам факт того, что мы называем это балансом жизни/работы, предполагает негативную сторону одного и необходимость балансировки этого при помощи другого.

. . .

Build an Audience from Scratch. How I would do things, if I had to start from zero.

english

By Paul Jarvis

Найти клиентов из воздуха: как я бы стал действовать, начиная с нуля

russian

Перевод Севан Авалян

Let’s say tomorrow I had to start my business from scratch. No existing clients, no existing following. How would I build an audience? How would I attract customers?

Скажем, завтра я с нуля начинаю свой бизнес. Нет клиентов, нет никакого понимания, что делать. Как мне построить мою аудиторию? Как привлечь клиентов?

We’ll suppose all of this, because lots of people start businesses every day without an existing group of people eager to work with them. They know how to do something well (their craft), but might not have customers at the start.

Мы все сталкиваемся со этими вопросами, так множество людей каждый день открывают свой бизнес без намёка на то, что с ними вообще кто-либо захочет работать. Они знают, как делать что-то хорошо, но поначалу все сидят без клиентов.

. . .

Why I (Still) Write Code

english

By Ka Wai Cheung

Почему я (всё ещё) пишу код?

russian

Перевод Пётр Соковых

For nearly two decades, I’ve been writing some form of code. But, the primary reason I code has changed over time.

Вот уже второй десяток лет, как я пишу код. Однако с течением времени причина, по которой я этим занимался, менялась.

. . .

How Smart People Deal With People They Don’t Like

english

By DAVID K. WILLIAM

Как умные люди ведут себя с людьми, которые им не нравятся

russian

Перевод Дмитрий Оськин

In a perfect world, each person we interact with would be nice, kind, considerate, mindful, generous, and more. They would get our jokes and we would get theirs. We would all thrive in a convivial atmosphere where no one was ever cross, upset, or maligned.

В идеальном мире все люди, с которыми нам придётся общаться, будут хорошими, добрыми, внимательными, умными, щедрыми. Им будут нравиться наши шутки, а нам – их. Мы будем жить в прекрасной среде, где никто никогда не бывает расстроен, никто не будет ругаться и клеветать на других.

. . .

Things I was unprepared for as a lead developer

english

By Pascal de Vink

К чему можно оказаться не готовым, став тим-лидом

russian

Перевод PayOnline

I’ve been a lead developer for 2 years. It has been quite a ride and there were a lot of things I was unprepared for. I’ve always been a software engineer, mostly involved with the actual code. People tell me I have a very natural way of leading, which is probably why I was asked for the job. However, I never before considered what it takes to lead an entire team of engineers. I wish I had more preparation beforehand. So to give you, the reader, a head start, these are the topics I was unprepared for, so you can hopefully be a better leader than I was. Mind you, I didn’t fail on all aspects, but most caught up with in me at one point in time.

До этого я был инженером и занимался непосредственно кодом. Мне говорили, что у меня хорошие лидерские качества, наверно, поэтому я и попросил о повышении. Я даже не задумывался, что значит управлять целой командой инженеров. Сейчас думаю, вот бы тогда у меня было побольше времени на подготовку. Итак, без лишних слов, вот вещи, к которым я оказался не готов.

Way less developing

Меньше заниматься разработкой

. . .

What Makes a Good Programmer Good?

english

By Josh Symonds

Что делает хорошего программиста хорошим?

russian

Перевод Дмитрий @vovochkin

I’ve worked with a lot of programmers over the years – some of them super amazing, and some distinctly lackluster. As I’ve had the pleasure of working with some very skilled individuals recently, I spent some time thinking about what I admire in them. What makes a good programmer so good, and a bad programmer so bad? Or, to mangle English a little bit, what makes a good programmer good?

Я работал со многими программистами на протяжении долгих лет — некоторые из них были очень яркими, а некоторые — определенно «никакими». Недавно я имел удовольствие работать с несколькими высококвалифицированными специалистами, так что я потратил немного времени в размышлениях, чем же я восхищаюсь в них. Что делает хорошего программиста таким хорошим, а плохого — таким плохим? Или, немного коверкая русский язык, что делает хорошего программиста хорошим?

Based on my experiences, being a great programmer has nothing to do with age, education, or how much money you make. It’s all in how you act and, more deeply, how you think. I’ve noticed a consistent set of habits in the programmers I admire. More than knowledge of their chosen language, deep understanding of data structures and algorithms, or even more than years of on-the-job experience – the way they communicate, the way they conduct themselves, and the way they approach programming speak volumes as to their amazing level of skill.

Исходя из своего опыта могу сказать, что «великолепие» программиста никак не связано с возрастом, образованием или финансовым состоянием. Это связано с тем, как вы действуете и, более детальнее, как вы думаете. Я заметил стойкий набор привычек у программистов, которыми я восхищаюсь. Более чем хорошее знание выбранного языка программирования, глубокое понимание структур данных и алгоритмов, более чем годы опыта работы, то, как они общаются, как они управляют собой и как они подходят к разработке — все это говорит об удивительном уровне их мастерства.

. . .

Don't Call Yourself A Programmer, And Other Career Advice

english

By Patrick McKenzie

Перестаньте называть себя программистом и другие карьерные советы

russian

Перевод kolupaeva

If there was one course I could add to every engineering education, it wouldn’t involve compilers or gates or time complexity. It would be Realities Of Your Industry 101, because we don’t teach them and this results in lots of unnecessary pain and suffering. This post aspires to be README.txt for your career as a young engineer. The goal is to make you happy, by filling in the gaps in your education regarding how the “real world” actually works. It took me about ten years and a lot of suffering to figure out some of this, starting from “fairly bright engineer with low self-confidence and zero practical knowledge of business.” I wouldn’t trust this as the definitive guide, but hopefully it will provide value over what your college Career Center isn’t telling you.

Есть один курс, который я бы добавил в программу обучения по всякой инженерной специальности, и он не о компиляторах или сложности алгоритмов. Это “Введение в реальность индустрии”, ибо об этом не говорят и это приводит к никому не нужным обломам. Эта статья претендует стать README.txt для молодого инженера в деле построения карьеры. Ее цель — сделать вас счастливее, заполнив пробелы в образовании относительно того, как работает реальный мир. Я не призываю следовать написанному как подробному руководству, но я надеюсь, что эта информация окажется для вас более ценной, чем то ничто, что вам рассказали об этом в университете.

90% of programming jobs are in creating Line of Business software: Economics 101: the price for anything (including you) is a function of the supply of it and demand for it. Let’s talk about the demand side first. Most software is not sold in boxes, available on the Internet, or downloaded from the App Store. Most software is boring one-off applications in corporations, under-girding every imaginable facet of the global economy. It tracks expenses, it optimizes shipping costs, it assists the accounting department in preparing projections, it helps design new widgets, it prices insurance policies, it flags orders for manual review by the fraud department, etc etc. Software solves business problems. Software often solves business problems despite being soul-crushingly boring and of minimal technical complexity. For example, consider an internal travel expense reporting form. Across a company with 2,000 employees, that might save 5,000 man-hours a year (at an average fully-loaded cost of $50 an hour) versus handling expenses on paper, for a savings of $250,000 a year. It does not matter to the company that the reporting form is the world’s simplest CRUD app, it only matters that it either saves the company costs or generates additional revenue.

90% работы для программиста — это корпоративное ПО Основы экономики: цена чего-угодно (включая вас) — это функция спроса и предложения. Давайте сначала посмотрим на спрос. Большинство ПО не продается в коробках и не доступно для скачивания в интернете или App Store. Большинство ПО — это тоскливые узкоспециальные корпоративные приложения, поддерживающие глобальную экономику со всех вообразимых сторон. Эти приложения подсчитывают издержки, оптимизируют расходы на пересылку, помогают составлять бухгалтерские отчеты, проектировать новые интерфейсы, вычислять цену страховки, помечать подозрительные заказы для ручной проверки и т.д. ПО решает проблемы бизнеса. ПО решает проблемы бизнеса несмотря на свою душераздирающую скучность и отсутствие технологической сложности. Например, представьте себе электронную форму отчета о командировочых расходах. Для компании размером в 2000 человек она может сэкономить порядка 5000 человеко-часов в год в сравнении с ручной обработкой бумаг, что при средней стоимости часа работы в $50 сэкономит $250,000. Компании все равно, что это самое примитивное на свете CRUD-приложение. Единственное, что имеет значение, это то, что оно сокращает издержки или генерирует прибыль.

. . .

The greatest program ever written

english

By

Величайшая программа из когда-либо написанных

russian

Перевод

I’m a programmer. I write games. Games programmers get a lot of respect, but none of them, not me, not Carmak, and not Abrash. None of them deserve the honour which I want to bestow on David Horne. This is because David Horne wrote the greatest program ever written: 1k chess on the ZX81.

Я программист. Я пишу игры. Программисты игр заслуживают уважения, но ни один из них, не я, не Carmak и не Abrash. Никто из них не заслуживает такой чести, которую я хочу даровать Дэвид Хорн. Потому что Дэвид Хорн написал самую величайшую программу из когда-либо написанных: шахматы размером 1 килобайт на ZX81.

David Horne is not an urban myth. David Horne achieved what many would even now consider impossible. He wrote a chess game, with AI, that ran on a poorly documented, buggy machine that contained only 1k of memory.

Дэвид Хорн — это не какая-нибудь байка. Он достиг того, что многие из нас вообще сочли бы невозможным. Он написал шахматы с искусственным интеллектом (!) для плохо документированной и полной багов машины, содержащей всего один килобайт памяти.

. . .

Why Every Developer Should Understand User-centered Design

english

By Paul Hershey

Почему каждый разработчик должен понимать, что такое дизайн, ориентированный на пользователя

russian

Перевод Sarkhan Hasanov

As a developer, there are few things more rewarding than bringing a new product to life — especially when users respond to it enthusiastically. You undoubtedly spend a great deal of time crafting its functionality, ensuring it responds quickly to user requests, and making sure your code doesn’t throw errors. When it’s done, receiving positive feedback is a reminder that it was all worth it.

Для разработчика нет ничего желаннее, чем вдохнуть жизнь в новый продукт, и увидеть, что пользователи с восторгом относятся к его работе. Вы, несомненно, потратили много времени на функциональность сайта, убедились, что запросы пользователей обрабатываются без задержек, а программный код не содержит ошибок. Когда все сделано, положительные отзывы о проделанной работе могут сказать, что все это было не зря.

But what happens when users don’t like or understand your product? It can feel defeating. The good news, though, is that there are methods you can implement to be sure your products are consistently amazing (meaning: users love them and keep coming back for more). And luckily enough, you’ll learn these methods in our new web design course, The Elements of Web Design! To get you started, today we’ll go over some things you should keep in mind when considering how users will interact with your product.

Однако, что, если пользователям не понравился ваш продукт, или он был встречен с непониманием? Это может показаться вам настоящей катастрофой. Не торопитесь впадать в депрессию, потому что есть хорошие новости: существуют методы, с помощью которых можно добиться того, чтобы ваши продукты неизменно встречались с энтузиазмом, а круг пользователей рос. Есть еще лучшие новости: предлагаем вам подборку статей про веб-дизайн. Но если вы начинающий, то следует начать отсюда. Для начала, хотелось бы остановиться на некоторых моментах, которые всегда следует учитывать при организации взаимодействия пользователя с вашим продуктом.

. . .

How you should choose which technology to learn next

english

By Itamar Turner-Trauring

Как выбрать технологию для изучения?

russian

Перевод Александр Курилкин

Keeping up with the growing software ecosystem — new databases, new programming languages, new web frameworks — becomes harder and harder every year as more and more software is written. It is impossible to learn all existing technologies, let alone the new ones being released every day. If you want to learn another programming language you can choose from Dart, Swift, Go, Idris, Futhark, Ceylon, Zimbu, Elm, Elixir, Vala, OCaml, LiveScript, Oz, R, TypeScript, PureScript, Haskell, F#, Scala, Dylan, Squeak, Julia, CoffeeScript… and about a thousand more, if you’re still awake. This stream of new technologies can be overwhelming, a constant worry that your skills are getting rusty and out of date.

Шагать в ногу со временем становится все сложнее — новые языки программирования, фреймворки, базы данных появляются практически ежемесячно, и выучить их все невозможно. Если вы вдруг решили выучить новый ЯП, то у вас богатый выбор: Dart, Swift, Go, Idris, Futhark, Ceylon, Zimbu, Elm, Elixir, Vala, OCaml, LiveScript, Oz, R, TypeScript, PureScript, Haskell, F#, Scala, Dylan, Squeak, Julia, CoffeeScript… и еще тысячи других. Поток новых технологий просто ошеломляет, а свои знания необходимо расширять, чтобы оставаться на плаву в IT-сфере и быть ценным работником.

Luckily you don’t need to learn all technologies, and you are likely to use only a small subset during your tenure as a programmer. Instead your goal should be to maximize your return on investment: learn the most useful tools, with the least amount of effort. How then should you choose which technologies to learn?

К счастью, знать всё, что используются в современном мире, совершенно необязательно. В работе вы будете использовать лишь небольшое количество современных технологий, а значит, учить их все не имеет смысла. Вместо этого стоит сконцентрироваться на изучении того, что наиболее окупит потраченные усилия — наиболее полезных инструментов, на освоение которых не потребуется много времени. Но как выбрать стоящую изучения технологию? Секрет прост.

. . .

Analysis Paralysis: Over-thinking and Knowing Too Much to Just CODE

english

By Scott Hanselman

Паралич анализа: вы знаете слишком много, чтобы просто писать код

russian

Перевод @a553

I read a post on ArsTechnica today called “I know too much to program quickly. What can I do?” that is summary of a StackOverflow question by Zilk, who says:

Прочитал сегодня пост на ArsTechnica «Я знаю слишком много чтобы программировать быстро. Что мне делать?» — это обзор вот этого вопроса на StackOverflow:

. . .