I’m a multi-skilled IT professional with a good all-round supervisory and technical expertise. Extensive, 20+ years of professional experience in software development allowed me to investigate computer science and software engineering inside out. During these years I built up a solid base of design patterns, software architectures and programming languages such as C/C++, Golang, Java, Python, SQL, Assembly (and many others). I worked on mission-critical and multi-channel applications, applying distributed computing, messaging, image/data processing and computer graphics techniques. I faced both architecture design and systems rearchitecting, microservices introduction and technology migration as well as company wide adoption of new technologies/methodologies multiple times.
As an entrepreneur I have built and grown teams and development organizations from the ground up (internal/out sourced/at customer site) focusing on software engineering
methodologies as well as recruiting, budget/financial control and operations support.
I am particularly interested in software testing methodologies, software quality metrics
and tools to make software development faster and better.
Currently leading the Italian development team for ScientiaMobile Inc, a Reston (US) based startup focused on image optimizing CDN and mobile detection technologies and services. Born in Dearborn Michigan and living in Italy since many years now I speak fluently both English and Italian, studied French and learned some Russian while working for some time for a Olivetti/Aeroflot project.
(or the Attraction for Complexity) There is a very common tendency in computer science and it is to complicate solutions. This complication is often referred as incidental/accidental complexity i.e. anything we coders/designers do to make more complex a simple matter. Some times this is called over engineering and stems from the best intentions :
Attraction to Complexity: there’s often a misconception that more complex solutions are inherently better or more sophisticated. This can lead to choosing complicated approaches over simpler, more effective ones.
Technological Enthusiasm: developers might be eager to try out new technologies, patterns, or architectures. While innovation is important, using new tech for its own sake can lead to unnecessary complexity.
Anticipating Future Needs: developers may try to build solutions that are overly flexible to accommodate potential future requirements. This often leads to complex designs that are not needed for the current scope of the project.
Lack of Experience or Misjudgment: less experienced developers might not yet have the insight to choose the simplest effective solution, while even seasoned developers can sometimes overestimate what’s necessary for a project.
Avoiding Refactoring: In an attempt to avoid refactoring in the future, developers might add layers of abstraction or additional features they think might be needed later, resulting in over-engineered solutions.
Miscommunication or Lack of Clear Requirements: without clear requirements or effective communication within a team, developers might make assumptions about what’s needed, leading to solutions that are more complex than necessary.
Premature Optimization: trying to optimize every aspect of a solution from the beginning can lead to complexity. The adage “premature optimization is the root of all evil” highlights the pitfalls of optimizing before it’s clear that performance is an issue.
Unclear Problem Definition: not fully understanding the problem that needs to be solved can result in solutions that are more complicated than needed. A clear problem definition is essential for a simple and effective solution.
Personal Preference or Style: sometimes, the preference for certain coding styles, architectures, or patterns can lead to more complex solutions, even if simpler alternatives would suffice.
Fear of Under-Engineering: there can be a fear of delivering a solution that appears under-engineered or too simplistic, leading to adding unnecessary features or layers of abstraction.
We all know Pascal language (less know about Algol or Oberon OS) and we might have heard that
“software is getting slower more rapidly than hardware is becoming faster”
or that
“What Intel giveth, Microsoft taketh away”
I prefer this quote :
“Reducing complexity and size must be the goal in every step—in system specification, design, and in detailed programming. A programmer’s competence should be judged by the ability to find simple solutions, certainly not by productivity measured in number of lines ejected per day. Prolific programmers contribute to certain disaster.”
You find them all here “A plea for lean software“. if you make code please read this 1995 paper.
Agile has failed ? I don’t think so : https://medium.com/developer-rants/agile-has-failed-officially-8136b0522c49 Anything applied as a religion is doomed to fail and the same is for Agile. You can’t take any methodology and apply it “as is” to a company or project or dev-team; you need to adapt it and not make the company/team adapt to it. What I hope is that we don’t trow away the good ideas of Agile (iterations/continuous delivery, attention to technical excellence, simplicity (avoiding over engineering) just to mention a few).
Reasons why you burnout swe : https://engineercodex.substack.com/p/how-to-burnout-a-software-engineer My list in order of priority : 1. don’t ship code (there is nothing worse than working months on something that is not going to prod or is lingering in the deploy queue) 2. Not trusting your engineers by telling them in fine detail how to do things. 3. Lack of Recognition (not reward, about the difference).
From a friend of mine substack, Chris Hedges talking about war : “But these words give me a balm to my grief, a momentary solace, a little understanding, as I stumble forward into the void.”
Yoshua Bengio (CA) and John Bunzl (UK), moderated by Nico A. Heller on strengths and limitations of current artificial intelligence, why it may become a dangerous instrument of disinformation, why superintelligent AI may be closer (years) than most previously expected (decades) and how this could yield to catastrophic outcomes – from AI-driven wars to the extreme risk of extinction. https://www.youtube.com/watch?v=07c1ZRUQOeY. Notes, general concepts from Bengio talk :
AI currently perceive the world and make sense of it with images, sound and text, generating content in all 3 areas. Current systems are not at the level of human intelligence, they master what psychologist call system 1 intelligence (intuition) : react to any question/context, no reasoning (or little reasoning) – arithmetic : simple operations with numbers ok, more complex (of the type we will need paper and pencil) they make mistakes. System 2 intelligence : explicit reasoning, you can plan, imagine. Ex: driving left hand roads after having driven right hand all life. We take 1 hour to adapt because we don’t use intuition but reasoning. AI will get there : how much time will take to bridge the gap between s1 and s2 ? nobody knows, could be close or take 10 years. Training data currently needs to be filtered to remove data that appears to be insulting, homophobic or racists, dangerous, inadequate. AI will get there too to avoid the need of preparing training material. Machines that are as intelligent as we are will be inevitably more intelligent than us because they are machines : immortal, don’t sleep, can exchange info at high speeds like if they were a huge brain. Humans have culture to try to simulate this.
pure intelectual power, completely detached from the goal. The goal will make the difference between a “good” AI and an “evil” one.
humans cannot turn off compassion (or just most people can’t) as it has been hardwired into us by evolution; machines can
Stating a goal in a precise way is probably impossible so even AI with good goals might behave evil.
Goals are not expressable, we can only give partial specifications
We’ll get to the point where the game will be : who’s AI is bigger/better/faster ?
Most important thing to reduce the probability of bad behavior connected to AI is to reduce the actors, materials, information, proliferation (like we did for atomic bombs) Regulatory frameworks are necessary.
On crypto and thieves : “In February 2022, a hacker stole 120,000 wrapped Ethereum from Wormhole, a cross-blockchain bridge” https://newsletter.mollywhite.net/p/oasis-defi-centralization – subscribe to Molly White newsletter for unbiased crypto news.
package main
import "fmt"
func main() {
var m = 0.1
var n = 0.2
fmt.Println(m + n)
var a = 0.1
var b = 6.0
fmt.Println(a * b)
var o = 0.6
var p = 0.3
fmt.Println(o + p)
var f = 1.39
fmt.Println(f * f)
const c = 1.39
fmt.Println(c * c)
}
0.30000000000000004
0.6000000000000001
0.8999999999999999
1.9320999999999997
1.9321
Reducing Cognitive load (Golab2022 notes) in code :
Line of Sight : 1st level, second level for error conditions
eliminate else, return early, avoid extra nesting, wrap in function
align the happy path
remove misterious booleans
Package Names : concise and clear, move on the calling side. No util/common/ packages, split
VCF East 2019 Bryan Kernigham interviews Ken Thompson : how unix, pipes, and other things like grep came out just to run nroff/troff for Bell Labs patents office https://youtu.be/EY6q5dv_B-o
Perche’ l’innovazione e’ cosi’ difficile in italia : qui
Questo non vale solo per la digitalizzazione, vale per l’industrializzazione e per il capitalismo. Prendo in prestito la domanda (e la risposta) di Roberto Maragliano “Perché i temi della maturità sono ancora così? Ce lo dice Camillo Olivetti (padre di Adriano) in un appunto del 1927: “L’istruzione della nostra borghesia ha un fondamento prettamente anti-industriale. Noi siamo ancora i figli dei Latini che lasciarono ai servi e ai liberti i lavori industriali e che in ben poco conto li ritennero, tanto che ci tramandarono i nomi dei più mediocri proconsoli e dei poetucoli ed istrioni che dilettarono la decadenza romana, ma non ci ricordarono neppure i nomi di quei sommi ingegneri che costruirono le strade gli acquedotti e i grandi monumenti dell’Impero Romano” (da Paolo Bricco, Adriano Olivetti, un italiano del Novecento, Rizzoli, appena uscito)”.
Broken Window Theory applied to software ( initial statement in “The Pragmatic Programmer” by Andrew Hunt and David Thomas, 1999 if I’m not wrong) interesting review and interesting to meet another fan of simplicity and minimalism in code.
Super, 10X, rockstar — these are names for developers who produce a lot of code or work in many development areas. Such developers sometimes build a reputation — and an ego. “These super developers usually make their code unnecessarily complex just because they can,” Rials said. Other team members struggle to comprehend and edit the complex code. These colleagues might even compliment the super developer about the code’s complexity, which encourages more of it. Businesses should empower junior developers to take a fresh look at code.
Bill Rials, associate director and professor at Tulane University’s School of Professional Advancement
How common the pattern above is ..
Composer, music theorist, architect, performance director and engineer https://en.wikipedia.org/wiki/Iannis_Xenakis (I love multi potential people). Known for his studies on Music generation software : author of UPIC, which inspired many other tools like Iannix, HighC, UPISketch. I was able to run HighC …
The importance of Rubber Ducking : a funny tool to do it alone ..
Ethical resources : sustainable, mindful, transparent, open and much more. Here’s a list of tools (browsers, search engines, email services, web hosting, tools for team collaboration, messaging, and a lot more) for a more ethical internet.
You’ve probably seen these acronyms around : SSG, SSR, MPA, SPA, PWA. Web design is getting complex and this tries to explain (with the help of other good content) what these acronyms mean :
PWA : Progressive Web App, web apps developed using a number of specific technologies and standard patterns to allow them to take advantage of both web and native app features. Not sure if this is a web design pattern
MPA : Multi Page Application, every operation requests data from server, receives a new page (html+css+js) and renders the data in the browser.
SPA : Single Page Application, performs inside a browser and does not require page reloading during its use. Initial html+cs+js is obtained from the server and then all login is done in js browser side.More info here and here
CSR : Client Side Rendering, all rendering happens in the browser. Use when UI is complex, lots of dynamic data, you need auth and SEO contents are not that many.
SSR : Server Side Rendering, as the acronyms imply, renders content in the server and sends ready .html+js files to the browser. Browser still executes js to reload pages. Use when UI has little interactivity, when you need best SEO and faster loading.
SSG : Static Site Generating, all pages are already generated and rendered server side.
There are several popular frameworks that can be used for static site generation (SSG) and server-side rendering (SSR).
For SSG, some popular options include Gatsby, Next.js, and Jekyll. These frameworks use a variety of technologies, such as React, Vue, and Ruby, to generate static HTML pages from dynamic content.
For SSR, some popular options include Express, Flask, and Hapi. These frameworks use Node.js and other technologies to generate the HTML for a page on the server and send it to the client.
Overall, there are many different frameworks available for both SSG and SSR, and the best choice will depend on the specific needs and goals of the project. It is important to carefully evaluate the features and capabilities of each framework to determine which one is the best fit for the project.
