The Weekly Top 7 DEV Articles You Should Read
Precision in Tech Discussion, FLOSS security, What Makes a Great Developer, Ukraine Hacking Campaign, Quitting Shopify, Web3 Security Risks, Nitpicky Code Reviews.
1- Precision In Technical Discussions
Precision is a fundamental characteristic of a fruitful technical discussion. In this article, Raphael enucleates how to achieve this goal. (04/02/2022)
https://rtpg.co/2022/02/04/precision-in-technical-discussions.html
TL;DR:
When working on the same domain, it's common for people to take shortcuts when describing something. Ambiguous statements can bring a fast switch of focus, from the subject of the discussion itself to a game of linguistic forensics. To achieve precision in technical discussions, it's insufficient to rely on the generic advice "imagine you are in the other person's shoes." We can instead rely on the following bits of advice.
Firstly we can make sure that the "WHO" and the "WHAT" are clear. If context and details are missing, it's mandatory to guide the reader towards collecting more information.
Secondly, by providing the evidence of the issue or behavior described, it's possible to turn conjectures into ironclad statements.
In addition, it's better to avoid analogies. Analogies work when things are the same, up until the point that things are different.
In conclusion, we should state facts first and leave opinions until later. We must fight the urge to provide the conclusion upfront without furnishing the evidence first. If the objective is to convince someone of an idea, you should first present the truth. The opinion should follow, and not anticipate facts.
2- The right thing for the wrong reasons: FLOSS doesn't imply security
Rohan Kumar dismantles an automated assumption. Free, Libre and Open-Source Software (FLOSS) isn't inherently more secure than costly, closed-source software. (04/02/2022)
https://seirdy.one/2022/02/02/floss-security.html
TL;DR:
The stance of the author is clear enough. It’s preferable to perform security analysis on binaries, without necessarily reading and analyzing the code.
First of all, vulnerability discovery doesn’t typically rely on source code analysis. Reading code is not enough to know how a program operates. The only way is actually to run the program. And that is the reason why most already employ techniques to analyze run-time behavior that doesn’t depend on source code.
It's way easier to treat the code under analysis as a black box. By mixing dynamic analysis with tools such as "Wireshark" or "Strace" and Binary analysis, together with memory dumps, it's possible to have a clear understanding of how a program operates - without accessing its source code. They make up the workings of most modern malware analysis.
To make the analysis more accurate, it's possible to use also Fuzzing, which is a technique that automates the process of causing a program to fail by generating random or malformed data to feed it.
There are of course some counter-arguments to this thesis. For example, Fuzzing could be implemented faster with access to the source code. In general, it's still possible (even if improbable) to spot a vulnerability reading source code.
3- What makes a great developer — It’s more than just good code!
Nicky Christensen, an experienced Team and Technical Lead, writes about peculiar characteristics, apart from technical abilities, that are needed to make a Great Developer. (03/02/2022)
https://blog.devgenius.io/what-makes-a-great-developer-its-more-than-just-good-code-b0da43278d79
TL;DR:
A great developer:
has to be humble, having the willingness to take responsibility for mistakes as well as to learn from mistakes.
needs to be a team player, empowering and caring about other team members.
Is capable of seeing the “big picture”. He doesn’t only focus on the task at hand but takes in good measure the complete path that the team is taking.
has to understand the value of planning, grooming, retrospectives, and all the various processes surrounding software development.
never stops learning.
has business acumen, he can see what and which features give business value for the company/product they are working on.
sees opportunities rather than limitations.
4- Microsoft Uncovers New Details of Russian Hacking Campaign Targeting Ukraine
Some appetizing details on the tactics and procedures adopted by the Russian hacking group named Gamaredon. (04/02/2022)
https://thehackernews.com/2022/02/microsoft-uncovers-new-details-of.html
TL;DR:
The cyberattacks aim at huge ranges of targets: government and military, law enforcement, and non-profit organizations. Those attacks compromised accounts at organizations critical to emergency response and ensuring the security of Ukrainian territory.
Primarily, those attacks leverage spear-phishing emails as an initial access vector, carrying attachments with malicious code. This code triggers a multi-stage process that culminates in the deployment of several binaries:
PowerPunch: a PowerShell-based downloader used to retrieve other executables remotely
QuietSieve: a .NET binary obfuscated with the main aim of data-exfiltration that can also receive and execute a remote payload from the operator and take screenshots of the compromised host every five minutes
Pterodo: a feature-rich backdoor that also includes a range of capabilities that makes analysis more difficult
5- Why I Quit Shopify After Five Months
Josh Simmons writes about leaving one of the most important companies in the modern world. Another story that belongs to the movement of the Great Resignation. (04/02/2022)
https://www.joshcsimmons.com/posts/why-i-quit-shopify
TL;DR:
Josh entered Shopify in a critical period when the company scaled its engineering department pretty aggressively. Shopify now is continuing to grow in the number of employees, and only six months in the company are needed to become an interviewer. It’s probably for this reason that the interview process wasn’t that good for Josh.
What is different from Faang companies, is that the interview process is more focused on the story of the developer rather than the capacity of solving code problems efficiently. Josh received and accepted an offer, despite that he had to downgrade his role to senior developer to mid, and he had to cut off his salary.
During his work at the company, even if he was hired as a front-end developer, he spent most of his time coding in Ruby. To maintain his skill up to date, he worked on some front-end projects in his spare time.
He quickly realized that his work at Shopify was not making him a better front-end developer. And that is the main reason he did quit. Although working at Shopify had several good aspects:
optimal work-life balance
great people
great codebase
6- Security Risks Facing Web3 Developers
New security challenges may surface in Web3 as more decentralized applications (dApps) emerge. (09/02/2022)
https://thenewstack.io/?p=21271935
TL;DR:
The first challenge the WEB3 has to face is the FOMO [fear of missing out]. This is bringing developers rushing in development, leaving not so much time up for security assessments. In addition, there is a great monetary value as an incentive for cyber attacks, and as there are lots of applications available, a lot of attack surface area.
Blockchains have already seen some significant security breaches. In the near past, a malicious actor was able to mint 120,000 ETH (approximately $360 million) in exploiting a bridge to the Solana blockchain. This loss was bailed out by investors to maintain the echo system active.
If investors need to routinely bail out Web3 projects to the tune of hundreds of millions of dollars, they may be willing to trade a slower development cycle to achieve fewer exploits.
To secure a web3 Application efficiently, we, as developers should treat our initial plunge as an exploratory journey. Review vulnerability write-ups and deconstructions of previous attacks. Projects affected by a compromise will typically post detailed write-ups.
7- Nitpicky Code Reviews Are a Drag
Steve Barnegren writes about the downsides of executing too obsessive code reviews. (09/02/2022)
https://www.steveonstuff.com/2022/02/09/nitpicky-code-reviews-are-are-drag.html
TL;DR:
When a developer who did stringent code reviews left the company, nothing happened to the quality of the code. Instead, it brought less noise in the code reviews and more focus on the critical things.
We should be aware of raising issues that, once addressed, don't change the behavior of the code in any way. Neither makes the code more maintainable or more scalable.
Our energies as humans are limited we should not waste our time on minor issues, just to make code more aesthetically pleasing. What makes code good is scaleable architecture, useful abstractions, good design.
We should, as developers, adopt the right mindset and focus just on what the code does, without being irked by minor issues.
"So my advice is: when you’re about to make a nitpicky suggestion, take a deep breath, and just… let it go."