So Hey You Should Stop Using Texts for Two-Factor Authentication

I’ve read this article explaining why messages over SMS should not be used for the ‘what you own’ in 2FA.

Tags: andy-greenberg, 2fa, sms, security, warning

Why I’d never work for Google, Twitter, or Facebook

I’ve read this article by David Bryant Copeland on why he would never work for these three companies: he doesn’t share the principles and values from these companies.

Tags: david-copeland, google, twitter, facebook, job-satisfaction, commitment

Design Thinking Needs To Think Bigger

I’ve read this article by STEVE VASSALLO on systems thinking and design thinking.

What makes a system a system rather than just a collection of parts is that the components are interconnected and interdependent

Tags: steve-vassallo, design-thinking, system-thinking, mental-model, emergence-point, leverage-point, iceberg-model

COBOL Is Everywhere. Who Will Maintain It?

I’ve read this article by David Cassel explaining the state of the COBOL systems at some banks and the difficulty of finding young COBOL programmers.

Tags: david-cassel, cobol, youth, team-management, hiring, bank, java, mainframe, legacy-system

You’re Too Busy. You Need a ‘Shultz Hour.’

I’ve read this article by David Leonhardt, about the Shultz Hour: time set aside to not be busy, so you can set aside the tactical topics and focus on the strategic topics.

“You waste years by not being able to waste hours.”

Amos Tversky (as Michael Lewis describes in his THE UNDOING PROJECT)

Tags: david-leonhardt, busyness, time-management, shultz-hour, connectedness, social-media, quote

Avoid these 35 habits that lead to unmaintainable code

I’ve read this article about habits that make writing software more difficult:

1. Saying “I’ll fix it later”, and never doing it
2. Insisting on a one-liner solution
3. Making pointless optimizations
4. Convincing yourself that styling issues are not that important
5. Sweeping things under the rug
6. Using names that don’t add information
7. Ignoring proven best practices
8. Abandoning plans too early
9. Insisting on a plan that has little chance of working
10. Working on your own all the time
11. Refusing to write bad code
12. Blaming others
13. Not sharing with your team what you’ve learned
14. Being too slow on giving feedback to managers/clients
15. Not using Google enough
16. Overvaluing your personal style
17. Having a personal attachment to your code
18. Not knowing how to optimize
19. Using the wrong tool for the job
20. Not bothering with mastering your tools and IDE
21. Ignoring error messages
22. Romanticizing your developer toolkit
23. Hardcoding values instead of making them configurable
24. Reinventing the wheel all the time
25. Blindly copy/pasting code
26. Not taking the time to learn how things really work
27. Having excessive confidence in your own code
28. Not thinking about the trade-offs of each design, solution, or library
29. Not getting help when you’re stuck
30. Writing tests to pass
31. Disregarding performance testing for critical cases
32. Not checking that your build works
33. Pushing large changes late, or leaving after making a large push
34. Disowning code you wrote
35. Ignoring the nonfunctional requirements

Tags: christian-maioli-mackeprang, maintanability, code, listicle, habit

JavaScript — A First-Class Language At Last

I’ve read this article by Tom Goldenberg defending javascript, citing sources on why it is a first-class language, the amount of job offers, and the state of the art in NodeJS.

Tags: tom-goldenberg, javascript, java, comparison, first-class, language, analysis

Why the 8-Hour Workday Doesn’t Work

I’ve read this article defending the removal of the 8-hour workday, preferring the division of time in slots. In the article, 52 minutes of highly focused work then 17 minutes of rest.

The key idea is the work-rest, no matter how big those slots are.

Gives tips on how to separate both, some other tips for improving your performance.

By Travis Bradberry

Tags: time-management, pomodoro-technique, travis-bradberry, time, workday

The dark side of extreme productivity, and how to steer back toward the light

I’ve read this article by Beau Carnes on how productivity can have a downside, how it can affect your healthy lifestyle. Explains effective vs efficient, productivity, silent retreat, prayer or meditation

The key is not to prioritize what’s on your schedule, but to schedule your priorities

Stephen Covey

Tags: beau-carnes, productivity, quote, stephen-covey, sustainable-pace

Dejé de leer

I’ve read this article by Catalina Bu on the tsundoku and how to read more. (In Spanish)

Tags: catalina-bu, tsundoku, reading, time-management, spanish

Hacked in Translation – from Subtitles to Complete Takeover

I’ve read this article about a vector to getting to user’s machines through the video player, using subtitle files. by Check Point Research Team.

Tags: check-point-research-team, security, vulnerability, vector, attack, subtitle, video-player

8 Teamwork Myths To Tackle At Your Office

I’ve read this article by Leah Ryder on remote work myths.

Tags: leah-ryder, productivity, myth, remote, remote-work

Why I think Elm is the Future of Front End Development

I’ve read this article by Rishi Goomar comparing reactredux to elm, comparing javascript to elm.

Tags: rishi-goomar, comparison, elm, javascript, react, redux, javascript-fatigue

Los viejos programadores nunca mueren, y Silicon Valley se está dando cuenta de ello

I’ve read this article by Javier Pastor on the age of the programmers in Silicon Valley. In Spanish.

Tags: spanish, javier-pastor, age, programmer, career-manager, silicon-valley

Creating a TensorFlow-powered ING API client

I’ve read this article by Francisco López on how he has implemented a small bot to click the virtual keyboard and connect to the bank website.

Tags: ing-direct, francisco-lopez, bot, opencv, tensorflow, machine-learning, python, banking, open-banking-data

Be a good mentor, not a dickhead

I’ve read this article by Edaqa Mortoray about traits of a mentor. https://dev.to/mortoray/be-a-good-mentor-not-a-dickhead

Tags: edaqa-mortoray, mentor, trait, skill, mentorship, apprentice, apprenticeship

The largest Git repo on the planet

I’ve read this article by Brian Harry on how Microsoft manages one of its big repositories. Explains how they have virtualized the git folder and the git workspace at Microsoft using gvfs. Explains how they have performed the improvements necessary to make it useful and usable to programmers.

They have support for clients, but what about Linux?

Tags: brian-harry, microsoft, continous-delivery, linux, windows, gvfs, repository, monorepo

Chapter 9: Learn to Write

Analogy of TDD to writing.

Explains how to write good email. Then, good documentation, then good API documentation

Chapter 8: Bootstrap a Greenfield System

Working on a brand new application can be a lot of fun. There’s no “baggage” from legacy code, no technical debt, and there’s a wonderful feeling of freshness when starting an app from scratch.

(p. 101)

The decisions you make […] can have a lasting impact

(p. 101)

8.1 Overview

When given a greenfield project […] you have two main goals:

• Make sure everyone involved in the project feels good about the initial direction and decisions being made
• Establish a location for developers to start contributing code

(p. 102)

Mention of the iteration Zero, that

[…] indicates that no direct business value is going to be delivered initially

(p. 102)

8.2 Understand the problem

You do your company a disservice to build an application you don’t think needs to exist.

To understand why the application should be built, find answers to these questions:

• What business problems will this application solve?
• Why is the proposed application the best solutiont o those problems?
• What other solutions were considered?

(p. 104)

Mentioning the importance of asking why about these problems, also, whether this decided solution is good / the best.

8.3 Understand the System’s Place in the Technical Architecture

Mention of the ‘technical architecture’:

existing applications and existing infrastructure

(p. 105)

8.4 Choose Technology

Using the Blessed Stack

Be prepared to heavily defend your position if you decide to not use the blessed stack, both to yourself and others. (paraphrased from p. 107)

Using a Different Technology

You must answer the question “Why shouldn’t I use the blessed stack?”

[…]

[…] your first duty is to deliver results.

(p. 108).

Also consider these factors:

• Fitness for purpose
• Performance
• Developer productivity
• Developer happiness - also called developer experience (DX)

(from p. 108)

8.5 Outline the Application’s Architecture

You want your application to ooze consistency

(p. 111)

you want to establish a “culture of consistency”

(p. 113)

Each developer should be encouraged to establish a convention when they first face the need to have one.

(p. 113)

[…] considering the political impact […] Since it often doesn’t matter what the decision is, making an unpopular decision can be little gain for a lot of trouble.

(p. 114)

8.7 Create a Minimum Deployable System

I like to think of deployment as the physical act of getting the code up in the production environment and launching as the act of allowing users access.

(p. 118)

The difference between deploying and launching. This can be enforced with some techniques to block/allow access, such as enabling/disabling these features or controlling access to said features.

Chapter 7: Make Technical Decisions

Opinions like this are often indicators of hidden facts that you have yet to identify

(p. 90)

Chapter 6: Play Well With Others

challenges you’ll face as a programmer is to explain what you do, or how you’ve done it, to someone who is not a programmer

Translating your work to non-technical people is a skill that can be more valuable than any specific technical knowledge you have. It’s what makes a senior developer in the eyes of others.

(p 77)

6.1 Empathize With Your Audience

these “interested parties” understand the problem more deeply than you, but lack the technical knowledge, skill, or time to solve it directly.

(p 78)

Instead of thinking of them as “pointy-haired bosses”, think of them as partners. They understand the problem and you know how to solve it. This “division of labor” is why teams can achieve greater things than any individual.

(p 79)

6.2 Adapt and Abstract Information

We want to adapt our terms to theirs, and we want to abstract away irrelevant information as much as we can.

(p 80)

When communicating with others, you need to learn how to speak the language.

(p 80)

Some tips:

• Avoid technical jargon of your own
• Listen carefully and ask questions
• Don’t “talk down”
• longer descriptive phrases in place of acronyms or other jargon

(p 81)

need to distill your message to its absolute minimum without giving out false information.

(p 82)

As a conclusion:

Being able to “talk the talk” with others can make you more effective and more valuable to your company. Being able to briefly summarize technical details even more so.

(p 87)

Chapter 5: Deal With Technical Debt and Slop

• Seeing legacy as tech debt that has been acquired
• Slop as source for sloppy code
• Chapter about understanding the difference between slop and technical debt.

Many developers, if they are feeling pressured to complete their work, would call this an acceptable compromise, promise to fix it later, and ship it

(p. 70)

Technical Debt is […] used to explain compromises in implementation that save cost now, at a larger future cost (just like real debt). […] technical debt is code written under certain assumptions that no longer hold.

(p. 72)

Although you’ll likely need to pay it off someday, you might not necessarily have to.

(p. 73)

Uses a marker (TECHDEBT) to explain what and why has been introduced. Also serves to find this debt later.