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
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:
- Saying “I’ll fix it later”, and never doing it
- Insisting on a one-liner solution
- Making pointless optimizations
- Convincing yourself that styling issues are not that important
- Sweeping things under the rug
- Using names that don’t add information
- Ignoring proven best practices
- Abandoning plans too early
- Insisting on a plan that has little chance of working
- Working on your own all the time
- Refusing to write bad code
- Blaming others
- Not sharing with your team what you’ve learned
- Being too slow on giving feedback to managers/clients
- Not using Google enough
- Overvaluing your personal style
- Having a personal attachment to your code
- Not knowing how to optimize
- Using the wrong tool for the job
- Not bothering with mastering your tools and IDE
- Ignoring error messages
- Romanticizing your developer toolkit
- Hardcoding values instead of making them configurable
- Reinventing the wheel all the time
- Blindly copy/pasting code
- Not taking the time to learn how things really work
- Having excessive confidence in your own code
- Not thinking about the trade-offs of each design, solution, or library
- Not getting help when you’re stuck
- Writing tests to pass
- Disregarding performance testing for critical cases
- Not checking that your build works
- Pushing large changes late, or leaving after making a large push
- Disowning code you wrote
- 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
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
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 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.