DEV Community: Sébastien D.

Advice for people getting started with Knowledge Management and Writing

Sébastien D. — Sun, 25 Aug 2024 08:10:14 +0000

Having used Obsidian for a few years extensively, creating products (e.g., the Obsidian Starter Kit), and coaching people about Knowledge Management, my recommendations would be:

Avoid spending too much time researching the topic. The first step is to create the habit, get used to the tool, and WRITE. All the rest is just procrastination in disguise (really!)
Start simple: Avoid complexity like the plague. Structure and plugins can come later, once you reach a critical mass of notes
Prefer a dead simple folder structure (e.g., one folder for everything!), tag your notes, and choose good names
Avoid long notes. Create "atomic" ones: short, focused on a single idea, and connected with other ones
Create a journal in Obsidian, and use it as the entry point: add your notes to your daily notes, and create separate notes only afterward. That helps focusing on WRITING, instead of having to worry about organizing, tagging, etc. Again, organizing can come over time, as needed
Don't consider your notes as final: they're forever drafts
Don't give up. Knowledge Management has a "startup problem". It takes time to reach the return on investment

Again, ignore the theory for a while, it won't help you now. You can always explore PARA, Zettelkasten, Johnny Decimal, and other things later on.

If you really reach the point where you feel overwhelmed with your notes, then maybe take a look at something like my Obsidian Starter Kit. Hundreds of people are happy with it. It's a 1:1 copy of the system I use for myself. It's powerful, but simple, and it stays out of the way. Its goal is to let people focus on writing: https://developassion.gumroad.com/l/obsidian-starter-kit

Useful resources

Obsidian tutorial: https://www.dsebastien.net/the-ultimate-beginners-guide-to-obsidian/
Note naming tips: https://www.dsebastien.net/the-art-of-note-naming-keys-to-effective-knowledge-management/
Avoid long notes: https://www.dsebastien.net/how-to-split-long-notes-into-atomic-notes-a-comprehensive-guide/
Atomic notes: https://www.dsebastien.net/the-value-of-atomic-notes/ How to connect ideas: https://www.dsebastien.net/how-to-connect-ideas-together/
How to tag: https://www.dsebastien.net/2022-05-17-why-and-how-to-tag-notes-in-your-pkm/
Evergreen notes: https://www.dsebastien.net/continuous-note-taking/
Gradual return of PKM: https://www.dsebastien.net/the-gradual-return-on-investment-of-pkm/
How I use daily notes: https://www.dsebastien.net/how-i-use-daily-notes/
How to structure daily notes in Obsidian: https://www.dsebastien.net/my-daily-note-template-in-obsidian/
My public notes (thousands of examples): https://notes.dsebastien.net/
My newsletter (I write about PKM all day long): https://www.dsebastien.net/tag/newsletter/

About Sébastien
I am Sébastien Dubois. You can follow me on X) 🐦

I am an author, founder, and coach. I write books and articles about Knowledge Work, Personal Knowledge Management, Note-taking, Lifelong Learning, Personal Organization, and Zen Productivity. I also craft lovely digital products . You can learn more about my projects here.

If you want to follow my work, then become a member.

Ready to get to the next level?

To embark on your Knowledge Management journey, consider investing in resources that will equip you with the tools and strategies you need. You can start by exploring the concepts and best practices with my Knowledge Management course 🔥.

Then, check out the Obsidian Starter Kit and the accompanying video course. It will give you a rock-solid starting point for your note-taking and Knowledge Management efforts.

If you want to take a more holistic approach, then the Knowledge Worker Kit is for you. It covers PKM, but expands into productivity, personal organization, project/task management, and more: https://developassion.gumroad.com/l/knowledge-worker-kit

My current Indie Hacking toolkit

Sébastien D. — Thu, 27 Jan 2022 21:39:25 +0000

I thought I could share my current Indie Hacking toolkit. Hopefully, you'll find something interesting in here! A large portion of those tools can be used for free.

Note that only a tiny fraction of those tools are necessary, depending on the business you create/run. Keep in mind that a toolbox is just something that contains a set of tools that you might need. You don't have to pick them all at once. They're in your toolbox, and you can pick them up when you need to use them. Moreover, you don't need to get all of those at once. You can get new tools when you actually need those 🔧.

Alright, let's go! 🚀

My favorite Personal Knowledge Management (PKM), note-taking & journaling tools

PKM: Obsidian (https://obsidian.md)
Journaling: LogSeq (https://logseq.com)
Shared knowledge, inventory, processes, etc: Notion (https://www.notion.so)
Capturing highlights: Readwise (https://readwise.io)
Mind maps: Freemind (http://freemind.sourceforge.net), Whimsical (https://whimsical.com)

My favorite productivity tools

Time blocking and focus: focusd, our upcoming project (https://focusd.app)
Time tracking: Clockify (https://clockify.me)
Tasks: Trello (https://trello.com)
Calendar: Google Calendar
Text expander: Espanso (https://espanso.org)
My time timer (https://amzn.to/3AEU9Hx)
And my whiteboard of course!

My favorite software development tools

IDE: IntelliJ (Feels so much better to use than VS Code), VS Code (because it's useful too from time to time) + VS Code extension packs (https://dsebastien.net/blog/2019-11-24-vs-code-extension-packs-to-boost-productivity)
SCM: Git + Hub (https://github.com/github/hub)
Git GUI: GitKraken (https://www.gitkraken.com/invite/jdXvWeMU). Very pleasing UI for Git, allowing to quickly add/remove hunks (my favorite feature of Git, along with rebase) (heads up: I'm an ambassador for them!)
Source Code hosting, CI & CD: GitHub & Gitlab
Code formatting: Prettier (https://prettier.io) because we have better things to do than format code by hand or waste time comparing code style diffs
Scripting & shell: Bash & ZSH, tmux
Windows Subsystem for Linux (WSL): To feel right at home even on Windows
ConEmu + Git Bash + Notepad++ when stuck in Windows-land, configured with a Quake-style dropdown terminal
Linux Terminal: Tilda (main now), Yakuake (past) and Terminator (I'll be back...)
Notepadqq on *nix
User Story Maps and brainstorming: Miro (https://www.miro.com)
UX & UI: Figma (https://figma.com)
Schemas: Diagram.net, Excalidraw (https://excalidraw.com), Visual Paradigm Community Edition
Logos: Logology (https://www.logology.co)
Documentation, knowledge base, processes, etc: Notion
Lightshot for screenshots (Windows)
Correcting mistyped commands: thefuck (https://github.com/nvbn/thefuck)
Testing API calls: HTTPIE (https://httpie.io) and Insomnia (https://insomnia.rest)
FTP & al: FileZilla (https://filezilla-project.org/)
Network analysis: WireShark (https://www.wireshark.org) and nmap
tldr for avoiding wasting days in man pages (https://tldr.sh)
Installers: SDKMan (https://sdkman.io), Winget (https://github.com/microsoft/winget-cli), Homebrew (https://brew.sh), Volta (https://volta.sh)
Spotify (can't live without this one)
f.lux to save my eyes (https://justgetflux.com)
The Chrome Dev Tools and tons of extensions

My current tech stack

Language: TypeScript
Front-end: Next.js, maybe soon Remix
UI: Tailwind
Back-end: NestJS on my most recent project, really enjoyed the DX
Monorepo: Nrwl NX (https://nx.dev/). Really can't live without this one
State machines: XState (https://xstate.js.org)
Immutability: Immer (https://immerjs.github.io/immer)
DB: PostgreSQL @ Supabase (or others), CouchDB
Authentication: Auth0
Infrastructure: Docker & Kubernetes, Minikube and microk8s for dev, kubectl/kubens (https://github.com/ahmetb/kubectx), Skaffold (https://skaffold.dev), Dive (https://github.com/wagoodman/dive)
Hosting: DigitalOcean, Vercel, Netlify
DNS: CloudFlare
Certificates: LetsEncrypt, mkcert for dev (https://github.com/FiloSottile/mkcert)
Reverse proxy: NGINX
Analytics: Plausible (https://plausible.io/sites)
Mails: Mailgun (https://www.mailgun.com)
Integration: Zapier (https://zapier.com)
NoCode: Bubble (https://bubble.io)

My favorite writing tools

Grammar, typos and complexity: Grammarly (https://app.grammarly.com) and Hemingway (https://hemingwayapp.com)
Alternatives: Rephrasely (https://rephrasely.com)
Blogging: My own site, Medium, HashNode and DEV.to
Fiction writing: Scrivener (https://www.literatureandlatte.com/scrivener/overview)

Where to find images and illustrations

Unsplash (https://unsplash.com)
Pexels (https://www.pexels.com)
Kaboompics (https://kaboompics.com)
unDraw (https://undraw.co)
Favicon (https://realfavicongenerator.net)
The Noun Project (https://thenounproject.com)

Where to find fonts

Where I store my files

Google Drive
Synology NAS (DS1812+)
Amazon S3
Digital Ocean

Remote backup services

Backblaze (https://www.backblaze.com)
Amazon Glacier (I'm moving away though)

Tools you can use to find product and domain names

Namecheap (https://www.namecheap.com)
Google domains (https://domains.google.com)
DreamHost (https://www.dreamhost.com)
Domain.garden (https://domain.garden)
Domainr (https://domainr.com)
Namelix (https://namelix.com)
Namae (https://namae.dev)

What I use to check social handles availability

Social handle availability:

NameCheckr (https://www.namecheckr.com)

What I use to find UI inspiration

Dribbble (https://dribbble.com)

Tools you can use to look for existing trademarks

USPTO (https://www.uspto.gov/trademarks/search)
BOIP (https://www.boip.int/en/entrepreneurs/trademarks)
WIPO (https://www3.wipo.int/branddb/en)

Tools I use for SEO

Ahrefs (https://ahrefs.com)
Wordtracker (https://www.wordtracker.com)
Sitebulb (https://sitebulb.com)
Keywords Everywhere (https://keywordseverywhere.com)
Keyword planner (https://ads.google.com/aw/keywordplanner)
Google Webmaster Tools
SEM Rush (https://www.semrush.com)
Detailed SEO Extension (https://chrome.google.com/webstore/detail/detailed-seo-extension/pfjdepjjfjjahkjfpkcgfmfhmnakjfba)
Ahrefs SEO Toolbar (https://ahrefs.com/seo-toolbar)
Linked Data vocabularies (https://schema.org)
Google Schema Markup Testing Tool (https://developers.google.com/search/docs/advanced/structured-data)

Tools I use to follow trends

Google Trends (https://trends.google.com/trends)
Exploding topics (https://explodingtopics.com)
Pinterest Trends (https://trends.pinterest.com)
Subreddit Stats (https://subredditstats.com/)

Tools I use for CRM, Invoicing, etc

Odoo (https://www.odoo.com)

Tools I use to create landing pages

Carrd (https://carrd.co)

Services to host and serve images

Cloudinary (https://cloudinary.com)

Password management tools

KeePass (yes, I'm old school)

Solutions for online banking and payments

Wise
PayPal
Stripe (https://stripe.com)

Tools to sell infoproducts

Gumroad (https://www.gumroad.com): great because it acts as the Merchant of Record (MoR)

Tools for publishing newsletters (free and paid)

Revue (https://www.getrevue.co) because of its Twitter integration
ConvertKit (https://convertkit.com)

Tools to create online polls

Typeform (https://www.typeform.com)

Tools to create Slide decks (😂)

Excalideck (https://excalideck.com)

Tools for video recording

Loom (https://www.loom.com)
Screencasts: Camtasia
Use DSRL as a Webcam: Sparkocam (https://sparkosoft.com/sparkocam)
Remove background: XSplit VCam
Record on phone: Filmic Pro (https://play.google.com/store/apps/details?id=com.filmic.filmicpro)

Tools for video editing

Adobe Premiere Pro

Tools for image editing

Minimize images: TinyPNG (https://tinypng.com) and ImageMagick (https://imagemagick.org)
Resize/convert images: ImageMagick (https://imagemagick.org) and Paint.net (https://www.getpaint.net)
Create animated GIFs: ScreenToGIF (https://www.screentogif.com)
Process photos: Adobe Lightroom
Have some 2D fun: Adobe Photoshop and Gimp (https://www.gimp.org)
Create/edit SVGs: Figma (vector drawing tools are awesome!) and InkScape (https://inkscape.org)
Create illustrations: Canva (https://www.canva.com)

Tools for 3D modeling

Blender (https://www.blender.org)

Tools for audio recording

Audacity (https://www.audacityteam.org)

Tools for streaming

StreamLabs OBS (https://streamlabs.com)

Communication tools

Twitter
Discord, Slack, Microsoft Teams
Calls: Zoom
Book meetings: Calendly (https://calendly.com)
Instant messaging: Telegram
Work & projects: LinkedIn, Polywork with a custom domain (https://updates.dsebastien.net)

Tools for audience building

FeedHive (https://feedhive.io)
TweetDeck (https://tweetdeck.twitter.com)
BlackMagic (trial for now) (https://blackmagic.so)
SparkToro (https://sparktoro.com)

Tools and sites for staying up to date

My Twitter lists (https://twitter.com/dSebastien/lists)
Feedly (https://feedly.com/)
Various podcasts (including the IH podcast)
Hacker News (https://news.ycombinator.com)
ProductHunt (https://www.producthunt.com)

Communities that support Indie Hackers and tools for community building/management

Rosie Sherry's wonderful Indiependent Community (https://gumroad.com/a/249779315/GoImj — full disclosure, I'm a member AND an affiliate)
Indie Worldwide (https://indieworldwide.co)
IndieHackers of course ;-)
Circle (https://circle.so)
Luma (https://lu.ma)
Butter (https://www.butter.us)

Conclusion

In this article, I've listed many of the tools in my toolbox. There are some more, but those are the main ones. You don't have to feel overwhelmed or intimidated by this list. You probably don't need many of those. There are an infinity of tools, but we should only care about those we really need. Don't bring more tools in your life than you need to.

That's it for today! ✨

About Sébastien

Hello everyone! I'm Sébastien Dubois. I'm an author, founder, and CTO. I write books and articles about programming (TypeScript, Web, React, Angular, NestJS, etc), personal knowledge management, personal organization, and productivity.

If you've enjoyed this article then subscribe to my newsletter: https://newsletter.dsebastien.net

You can follow me on Twitter: https://twitter.com/dSebastien 🐦

How to think logically

Sébastien D. — Sun, 16 Jan 2022 09:15:56 +0000

One of the most important skills for knowledge workers is logical thinking/reasoning. It's of course also true for software crafters. In this article, I'll explore what it means to think logically.

This content is part of the first volume of my Dev Concepts series of books.

Why are analytical skills important?

Like our computers, our brains need to have enough "raw computing power". Analytical skills help us to analyze/process and understand information faster. These include logical reasoning, data analysis, critical thinking, research, forecasting, problem-solving, data mining, reporting, organization, etc.

The good news is that analytical skills are not innate. You can train yours, and improve.

Useful references:

What does it mean to think logically?

Thinking logically is all about thinking in steps. It's about going from ideas/observations/facts, making assumptions, validating those, and reaching conclusions. Again and again, and again.

Cogito, ergo sum. I think, therefore I am. —René Descartes, Discourse on the Method

Logical thinking is mainly related to the left side of the brain, which is all about logic and control (facts, patterns, words, language, perception, order, time, comprehension, etc). The right side of the brain is more closely related to emotions, creativity, and looking at the big picture. We all have a dominant side; either more logical or more creative. But, luckily, we can strengthen both sides at will; logical thinking is certainly not an innate talent. We can all learn and improve.

Programming is a great way to improve your reasoning skills because you'll need to apply logical thinking all the time. While designing your system, while coding it, and of course while troubleshooting issues.

Arguments, premises, ideas, claims, logical reasoning, deduction, induction and abduction

Dubito, ergo cogito, ergo sum. I doubt, therefore I think, therefore I am. — Antoine Léonard Thomas

The following argument terminology diagram, taken from Wikipedia is quite interesting and worth exploring a bit:

Based on arguments/premises/ideas/claims, each having a truth value (i.e., true or false), we try to reach conclusions using deduction or induction. When using deduction, the conclusions follow from the premises. When using induction, the conclusions follow from the premises... with some level of certainty.

With deduction, our conclusions may be valid or invalid, demonstrating sound or unsound reasoning. With induction, the reasoning may be cogent or uncogent, depending on the level of certainty of our reasoning. I just wanted to mention those because both deduction and induction are super useful "tools" for going from issues to solutions, and it's useful to pay attention to which kind of reasoning we're using while solving problems.

Often, we also use abduction to find solutions. Abduction is basically inference to reach the most likely conclusion. We often use abduction while developing because we lack time to verify our conclusions and instead have to use our gut feeling. Another reason to use abduction is also the cheapness of trying things out. More often than not, we can pick a good candidate solution and try it out quickly (i.e., we use empirical evidence). Abduction works better and better as you get more experienced in a specific domain. For instance, once you'll have solved a thousand bugs with a specific technology stack, then your deduction/abduction skills should be much stronger in that domain.

Let's take an example: I've used Java and Spring for a number of years. When I start a Spring-based application, and it crashes with an error message, it doesn't take me long to figure out what's going on and make good guesses about potential solutions.

Whatever problem you're working on, make sure to evaluate the pros and cons and to test-drive solutions to increase confidence in your reasoning

The stronger your logical thinking skills get, the faster you'll identify inconsistencies, and errors in reasoning. This will help you to better judge arguments, ideas and proposals, and influence things for the best. Critical thinking is very important in this regard.

The definition of insanity is doing the same thing over and over again, but expecting different results. — Albert Einstein

In IT, we often think we're going crazy when we're in front of a problem that we don't understand. But it's all right (really :p). Software systems are deterministic by nature, so there's almost always a very logical explanation; it's just that there are so many inter-related parts that problems quickly get complicated to understand.

Useful references:

Conclusion

In this article, I've discussed the importance of cultivating a logical thought process. Logic is key for knowledge workers in general and software crafters in particular. That is why I encourage you to train and improve your analytical skills.

In future articles, I'll explore different approaches we can use to analyze and solve problems in a consistent and systematic way.

That's it for today! ✨

About Sébastien

If you've enjoyed this article then subscribe to my newsletter: https://newsletter.dsebastien.net

You can follow me on Twitter: https://twitter.com/dSebastien 🐦

Why craftsmanship matters

Sébastien D. — Wed, 03 Nov 2021 07:54:13 +0000

This is a guest post written by Yennick Trevels, a fellow software craftsman.

As customers we like beautiful products, quality products that can last for years, products we don't have to worry about and which just work. These products typically come with a higher cost attached to them, but we're willing to pay for it because the product or service makes our life easier or more colourful. But sometimes we get tempted into buying the cheaper product, or going with the cheaper contractor. When we do, it typically already starts with the ordering process that isn't giving us the advice that we actually need, but we decide to order anyway. Time goes by, and we haven't received an update on the ordering status, so we decide to call them. Turns out they forgot to send the product but promise they will send it immediately. The day of delivery is finally there and we open the package. The result is pretty lifeless, grey, but does the job...until it starts to break down after a month of use. It's then when we ask ourselves why we didn't go for the product or service that clearly was better in terms of quality, made by a craftsman but more expensive.

Clearly being a craftsman is important, but it requires a long-term consistent investment. So why should you start investing in it early to reap the benefits later, and what are these benefits exactly?

What is craftsmanship

Craftsmanship, the art of efficiently making beautiful and high quality products. It has been around for thousands of years. Used by all kinds of professions to differentiate themselves from their competitors, for their love of the craft, to reach customers that enjoy well-crafted products and to find a market where price isn't the only determining factor.

It starts with learning to use the right tools for the job and knowing how to select these tools. Truly understanding what makes a great tool and even knowing how to create the necessary tooling. Without a good set of tools, it is hard to be efficient and to deliver that consistent quality.
Learning to craft a quality product, to iterate on it and harden it. To research new concepts that give you insights into how to craft even better products, concepts which will last for a long time.
But being a craftsman doesn't stop at the technical level, it's also about being an efficient communicator and planner. Knowing how to gather requirements, how to plan the work and communicate progress.

Craftsmanship is a never-ending effort to improve one's craft.

It differentiates you

Software engineering is a highly sought after profession, but still a competitive one. If you just look at the gruelling interview processes some companies employ, you better stand out from the crowd. But how do you stand out?
Craftsmen of old practiced their craft in a public area, for all to see how they start from a raw material and end up with a product that is tuned to perfection. People would notice, would be convinced of the quality and be glad to pay a premium. Word of mouth would spread quickly, providing a solid stream of work for the craftsman.

As software engineers we can do the same, by sharing our knowledge and building software in the open. It's our way of displaying our skills, our craftsmanship, to the world. When you build valuable software and share knowledge, word about your work will spread more easily (via Twitter, in companies, in communities, ...). It all works towards creating trust, without people actually having worked with you. It makes you the easier choice over someone else.

While working in the open certainly helps to differentiate you, it's the private work that also slowly but steadily builds your reputation. When working on projects you will quickly notice those developers who are underperforming, and those that have clearly invested in their craft and stand out from the crowd. It's the last category of developers who will generate a positive word of mouth. When people move on to other companies and that company is looking to hire more people, their names will come up. Don't underestimate the number of people you work with over the years and how this can quickly snowball in building a positive name in the industry. When others are willing to vouch for you, it's probably the most effective way to dodge those gruelling interview rounds.

It makes you reliable

As a customer, the last thing you want to do is having to micro-manage your contractor. Double-checking the quality they deliver, following-up with their progress, or even having to tell them how to do their job. You paid them (good) money to solve a problem of yours, so that you don't have to worry about it.
This is where your qualities as a craftsman come in, which make you a reliable partner to work with. Customers can expect solid advice, a quality product and clear communication. You become the go-to worry-free solution for customers who value their time and are willing to pay for it.

It builds your network

Guilds have always been a place where craftsman gather, share their knowledge and help each other. In our field of software engineering we come together in user groups and meetups, both online and offline. Consistently being involved in and contributing to those groups will build a relationship with the other members, it builds trust. If you then also display proficiency in your craft and willingness to help others, they will also gladly send work your way.

It makes you of higher value

When you don't consistently invest in your craft, you won't have anything to compete on except price. This makes you a low-margin commodity. A craftsman on the other hand has a unique set of skills or products for sale, which makes price less of a factor. As a craftsman it's easier to build a loyal and returning customer base, because they won't simply compare you on price. The consistent output of quality results also makes it so that price increases won't make your customers switch to the competition as easily, because that has now become a high-risk action (do they really want to risk worse results for a slight price increase?!).
And yes, you can sell a turd with good marketing and make a lot of money, but it's much easier to market and sell the qualities of a well-crafted product or service.

Conclusion

In-depth articles on how to improve one's craftsmanship can be easily seen as "something fluffy that developers waste time on" when you don't look at the bigger picture. But those small gems of knowledge keep adding up and when applied consistently are part of making you a craftsman. They not only feed our inner geek, but have a long-lasting impact on our career as a software developer.

About Yennick Trevels

Yennick has been practicing and applying his craft as a software developer for over 15 years in various roles (junior-senior software engineer, consultant, technical team lead, self-employed developer) for various companies (startups, enterprise companies, government). He's now sharing his knowledge on building a career in software engineering on digitalbuff.dev.

That’s it for today!

PS: check out the Dev Concepts collection of e-books, join the Software Crafters community, the Personal Knowledge Management community, and come say hi on Twitter!

Getting started with Svelte, Tailwind, and Nrwl NX

Sébastien D. — Sun, 17 Oct 2021 23:21:26 +0000

In this article, I'll show you how to create a Svelte application with Nrwl NX and how install/configure Tailwind.

Tailwind is more popular than ever. If you've been following me, you know that I'm a huge fan. Recently I've started exploring Svelte, and wanted to know how to combine it with Tailwind. Not only that, but I also wanted to use Nrwl NX. This is a summary of my findings.

This is a short, but very practical article. If you hope to learn how Svelte/Tailwind work and why you should use those then this article is not for you.

Battleplan

First, we'll create a Nrwl NX workspace to structure our project.

Once we're done, we'll install the Svelte plugin into the workspace, and we'll use it to create our Svelte application.

Then, we'll install Tailwind, and a few supporting tools (e.g., PostCSS and autoprefixer). After that, we'll configure Tailwind, PostCSS, and our Svelte application. Finally, we'll load Tailwind's base styles in our application, and we'll add some styling.

Creating the Nx workspace

NX is a really powerful tool that I use in most of my projects. NX supports many frameworks and programming languages.

Creating an Nx workspace is as simple as running the following command:

npx create-nx-workspace <workspace name>

At the moment, NX does not natively support Svelte, so we need to create an empty workspace. The create-nx-workspace command should generate the following structure for you:

This is the standard structure for Nx workspaces. The key elements are:

The apps folder, which will later contain our Svelte application
The libs folder, which we can use to host parts of our monorepo to make those easily reusable across projects
The nx.json file, which is the configuration file of Nx
The package.json file in which we can manage our dependencies
The workspace.json file, which is the configuration file for our Nx workspace

Installing the Svelte plugin for Nx

Now that our workspace is created, we need to install the Svelte community plugin, created and maintained by Dominik Pieper. This plugin makes it possible to create and build Svelte applications in a Nrwl NX workspace. You can find the official documentation here.

For this example, I'll use npm, but feel free to use yarn if you prefer. Installing the plugin is quite straightforward:

npm install @nxext/svelte --save

Once done, we have access to the schematics and builders.

Creating the Svelte application

The Svelte plugin for NX includes a schematic that we will use to create our Svelte application:

npx nx g @nxext/svelte:app app_name

This command will generate the application and store it inside the apps/<app_name> folder. Pick any name you fancy.

Inside that folder, you should find the following:

The code of the application can be found under src, while the assets (e.g., images, fonts, global styles, etc) will go into the public folder.

Notice the svelte.config.cjs file. This is the configuration file for Svelte. We'll adapt it in a minute.

Svelte application configuration

In the previous section, I've mentioned the svelte.config.cjs file that you should find under apps/<app name>. Let's take a look at it:

All this file does is export a configuration object for the build of our Svelte application. By default, it uses the svelte-preprocess package, which is a preprocessor for Svelte providing support for PostCSS, SCSS, TypeScript, and much more.

The question is: how is that file used by the build system? To answer that question, we need to look at the workspace.json file at the root of the NX workspace. It has been updated by the Svelte plugin for NX:

As you can see, the different targets (e.g., build and serve) use a specific executor: @nxext/svelte:build, which is provided by the Svelte plugin for NX. That executor supports a number of options. In the example above, we care about the svelteConfig setting, which defines the configuration file to use for Svelte.

When we build the Svelte application using NX, here's what happens:

NX loads the workspace.json file to know about the different applications and libraries
It executes the requested operation (let's imagine a build of the Svelte app)
When the Svelte app is being built, NX knows which executor to launch to take care of the grunt's work
The Svelte NX plugin executor loads its configuration and notices the svelteConfig option. It loads the corresponding file (i.e., svelte.config.cjs), and updates its default build configuration accordingly

Installing Tailwind

To install Tailwind, we need to add a few packages to our project, as explained in the official documentation:

npm install -D tailwindcss@latest postcss@latest autoprefixer@latest

We'll also install a few additional ones:

npm install -D postcss-import@latest postcss-preset-env@latest node-sass@latest

Next up we'll configure Tailwind.

Configuring Tailwind

To configure Tailwind, create a file called tailwind.config.js at the root of the NX workspace with the following contents:

This configuration enables the JIT mode of Tailwind and configures PurgeCSS properly. If you want to know more, check out the official documentation of Tailwind.

Now, we need to configure PostCSS.

Configuring PostCSS

PostCSS is a CSS processor that Tailwind relies on to do its magic.

The details about PostCSS are out of scope for this article, but let me explain something anyway. One thing you need to understand is that PostCSS can be used to define a processing pipeline for CSS code. The very first step of that pipeline receives the CSS as you wrote it, and processes it in some way. Then, the next step receives the result of the previous one and applies its own processing. And so on and so on. Now that you know this, you'll understand that the order of the elements in the configuration below does matter.

Go ahead and create a file called postcss.config.js at the root of the NX workspace, with the following contents:

What does this do?

First, we apply the postcss-import plugin, which adds support for the @import syntax in our CSS code
Second, we enable Tailwind and its support for CSS nesting
Third, we enable the postcss-preset-env plugin, which adds support for many other cool things

Alright, our CSS processing pipeline is configured!

Loading our PostCSS configuration

By default, the Svelte plugin for Nrwl NX uses its own Svelte preprocessing configuration. To make sure that our PostCSS configuration is loaded, we need to adapt the Svelte configuration file that we saw earlier.

Open up the svelte.config.cjs file under apps/<app name> and adapt it as follows:

As you can see, all we did was pass a configuration to the sveltePreprocess method and define the postcss configuration, associating it with an empty object. We only did this to replace the default postcss configuration included by the Svelte NX plugin. This ensures that our own PostCSS configuration is loaded.

Load Tailwind in the Svelte application

We're almost ready to start using Tailwind in our code.

The next thing we need to do is load the default styles of Tailwind. To do so, go ahead and create a file called Tailwind.svelte under apps/<app name>/src, with the following contents:

There are a few things to notice here:

We have marked the styles as global to make sure that those get applied on the global scope
We have set lang="postcss" to state that we're using PostCSS
We have loaded Tailwind's global styles using the @tailwind directive

Next, we need to load and use our Tailwind component inside the App component. Open the src/<app name>/src/App.svelte file and adapt the contents as follows:

What we did here is simply import the Tailwind.svelte file, and use it.

We're done with the configuration! Great.

Running the application

To run the application, we can now use the following command:

npx nx serve <app_name>

I recommend getting used to the nx command, which is the CLI of Nrxl NX.

If you're anything like me, then you might want to update the scripts section of your package.json file:

The names of the script should be self-descriptive. Just replace <app_name> with the application name you've chosen.

To run our application, we can now use npm start

To learn more, make sure to look at the NX CLI documentation.

Alright, we can now start playing with Tailwind!

Using Tailwind

Let's look at a few ways we can use Tailwind in our Svelte application. Edit the App.svelte file again as follows:

In this example, we've used Tailwind in three different ways:

Inside the HTML template, we've used class="..." to modify the styles of an element using Tailwind. This is the approach you can find in most Tailwind examples out there
Inside the style tag, we've defined global styles by using the :global scope supported by Svelte, and we've defined our styles using the @apply directive
Inside the style tag, we've defined a class called example, in which we've also used @apply. This approach creates locally scoped styles that only exist for the current component.

If you look at the application now, it should look like this:

Template

If you're in a hurry, then you can use the template I've prepared and published on Github with the results of this experiment. You can find it here: https://github.com/dsebastien/svelte-tailwind-nx-template

Conclusion

In this article, I've explained how to create a Svelte application using Nrwl NX. I've also covered how to add Tailwind support. Hopefully, this will have taught you a few things about how to configure Svelte applications, PostCSS and Tailwind.

That’s it for today!

PS: check out the Dev Concepts collection of e-books, join the Software Crafters community, the Personal Knowledge Management community, and come say hi on Twitter!

Problem-solving 101

Sébastien D. — Sat, 11 Sep 2021 08:04:51 +0000

In this article, I want to discuss problem-solving, one of the key skills that software developers need to master. As a software developer, you'll face problems all day long. IT in general and software development in particular is really all about solving problems. If you don't enjoy doing that, then you might not like software development all that much.

This content is part of the first volume of my Dev Concepts series of books.

Early days

In your early days as a developer, you'll spend a lot of time fighting against compilers, interpreters and linters. Why is this expression invalid? What is wrong with that function? What type should be used here? etc. Over time, once you overcome those learning difficulties, you'll get to bang your hand against the wall for more "important" issues such as:

How should we call this variable?
Haven't I imported that module?
Why is that value null at this point?
Shouldn't this be true at this point?
What was I doing ten minutes ago?

Just kidding! More seriously though, because of the constant trial and error process that you'll go through over the years, you'll face and resolve the same kinds of issues over and over again, albeit in different forms. It'll gradually become easier and easier for you to solve those issues. But new variants will emerge, always surprising you. Like viruses, there are always new problem variants.

Also, the more experienced you become, the more complex the problems you'll have to solve (the most complex ones always being about team collaboration). The other fun part as your experience grows is that you'll be able to anticipate problems and avoid some of them, for instance by creating more solid architectures/designs from the beginning.

When you are constantly facing issues, there are two main possible reactions: go mad or find it amusing, and move forward with the resolution of the new puzzle at hand. Hopefully, you'll be part of the second group. Sometimes, it'll take you a few minutes to solve an issue, and it won't trouble you much. But sometimes, issues will take hours or even days to be fixed, which can be hard on your morale, especially when you feel the pressure. There are also problems that you won't be able to crack and for which you and your teams will have to find external help, or workarounds.

Problem-solving cycle and approaches

Problem-solving can be tackled using a systematic approach. For instance, with the problem-solving cycle:

Recognize the problem: Before anything else, we need to see that there's a problem
Define the problem: We need to clarify what needs to be solved precisely
Develop a strategy to fix it
Organize information: What information do we have about the problem, what do we have to figure out, etc
Track progress: If we don't track our progress, then we risk spending too much time/energy. By evaluating progress, we'll be able to devise/try other strategies if needed
Evaluate found solutions (correctness, efficiency, etc): Especially useful if there are multiple solutions
Remember: Keep track of previously encountered problems, and their solutions to avoid having to find the same solutions again in the future

While analyzing problems, we can create an argument map, which is a useful tool to visualize the problem space. We can also make use of many other problem structuring methods.

Reformulating a problem is also very useful to make sure that it is clearly understood. Once clearly articulated, it should be simplified/reduced as much as possible. The goal is to simplify, focus on the essential and remove all the noise.

Brainstorming: Identify many ideas and potential solutions without judging those immediately
Analogies: Compare with other similar problems
Divide and conquer: Break down the problem in smaller, more easily solvable parts
Abstraction: Solve the problem on paper/in thought/on a prototype before solving it on the real system
Hypothesis validation: Validate parts of the solution
Root cause analysis: Identify the real source of the problem
Elimination: Rework or even eliminate a system or subsystem to make problems disappear altogether. Sometimes, eliminating the source of a problem is the fastest way to move forward
etc

For instance, we can create an issue tree, which visualizes the possible solutions to a problem and explore those separately. For root cause analysis, we can use the five whys technique and/or Ishikawa diagrams.

We can also use mind maps, which are one of the more powerful tools at our disposal to organize information/knowledge and analyze concepts/ideas. I'm a huge fan of mind maps. Mind maps are also very useful to use when trying to solve problems.

In general, visualizations and diagrammatic reasoning helps a lot, so don't hesitate to read articles/books about visualization techniques; it will, prove useful.

As professional problem solvers, there's a true pleasure when we finally get to the "Aha!" moment (also known as the Eureka effect); when the puzzle is finally solved. It only lasts an instant (because the next problem is already in front of you), but that moment is bliss. Sometimes the solution will come out of the blue. Many developers have already gone to sleep with an issue on their mind, and with a solution at hand in the morning.

In IT, problems often have many possible solutions. Of course, some are better than others, but it's not always obvious.

References

The Ideal Problem Solver: A Guide for Improving Thinking, Learning, and Creativity by John D. Bransford and Barry S. Stein
Problem solving
Cracked it!: How to solve big problems by Bernard Garrette, Corey Phelps and Olivier Sibony
Issue tree
Five whys technique
Ishikawa diagrams
Mind maps
Mind Map Mastery by Tony Buzan
Diagrammatic reasoning
Eureka effect
How to Solve It by G. Polya
Thinking, Fast and Slow by Daniel Kahneman

Conclusion

In this article, I've discussed problem-solving skills, which are key for all software crafters. I've covered the problem-solving cycle, as well as a number of approaches you can take to tackle the most complex problems. Make sure to check out the references that I've shared above, as those contain many more keys to help you solve the fascinating puzzles you'll be confronted with.

Problem-solving does require a particular mindset/thought process, an analytical mind, and specific skills that I'll cover in later articles.

What is your favorite approach to solve problems?

That’s it for today!

PS: If you want to learn more about software/Web/product development, then subscribe to my newsletter, check out my Dev Concepts books, join the Software Crafters community, and come say hi on Twitter!

Quality vs user satisfaction

Sébastien D. — Fri, 03 Sep 2021 15:37:30 +0000

Software crafters care a lot about the quality of their work, but business realities are generally much more important.

As a software crafter, you'll often be faced with the following conundrum: how to deliver the best possible quality results, hence satisfying the crafter in you, while pleasing end users, who usually want high-quality results yesterday?

Let's explore this subject together. This content is part of the first volume of my Dev Concepts series of books.

Tradeoffs and responsibilities

It's always a question of balance. Software crafters should generally strive for better quality but, always have to make tradeoffs. Satisfying user needs and respecting hard deadlines always has priority, but it doesn't mean that you should always give up on quality.

As a professional, you should dare to question business choices and deadlines. You should also provide information and bring clarity. Your customers deserve to know about their options, the tradeoffs involved and need to be guided towards better choices. Moreover, quality is also closely related to user satisfaction, even if it isn't always obvious.

Software quality facets

Software quality is composed of both external and internal elements. External quality is usually much more tangible for end users. For instance, users of a system only see the user interface and its behavior. If the quality of the user interface deteriorates, then it'll be discovered rather quickly. Internal quality has more to do with the robustness of the system and its reliability.

If you cut corners on the internal quality, then it will also impact end users, but in different and seemingly less obvious ways. They'll receive incorrect results, or calculations will take much longer than they should, etc. The system might crash unexpectedly, and the defect rate might increase drastically. It might also take longer and longer to deliver new features over time, as more and more time is spent fixing bugs and putting out fires. Most importantly, quick and dirty can sometimes have dramatic consequences (e.g., reputation & financial) on businesses.

High expectations

Interestingly, our expectations towards IT systems are heavily influenced by the applications we use on a daily basis in our lives (e.g., Gmail, Office 365, etc). This translates into high expectations from customers, who don't understand (or care for that matter!) about the complexity of achieving the same results as the biggest organizations in the world. Chances are that you are not working for Google, Microsoft, Facebook, Amazon, Apple, and the like. This means that you will have limited resources at your disposal, varying skill sets, and obviously tradeoffs to make. Make sure to inform customers about the complexity of their requests, and bring them "back down to earth".

The constant tension between quality and cost

We are all used to the quality vs cost relationship. Often in real life, if we pay less, then we get tend to get lower quality, and vice versa. This is not necessarily true with software. There are always shades of gray. Let's consider a few more dimensions to better understand the possible solutions:

As shown on this wonderful "flower diagram" (yes, just made that up), there are a few closely related concepts:

Scope: We can decide to develop fewer features, or to simplify the ones on the roadmap of the project
Time: We can change the timeline to be able to reach the required quality level while delivering the expected features
Quality: We can decide to make quality trade-offs and thus reduce the (immediate) costs while keeping the initial timeline
Risks: We can accept taking more risks

Whichever approach you pick, all the dimensions will be impacted. For example, reducing the available time by 10 while keeping the same scope will most probably have a catastrophic impact on quality (and project risks). Reducing quality will increase risks, time to completion and thus overall costs, etc.

Clear and timely communication is critical for success. Before deciding to lower internal or external quality to meet deadlines, make sure to understand the possible tradeoffs, and to explain those to stakeholders so that conscious decisions can be taken by the business. A Strengths Weaknesses Opportunities Threats (SWOT) analysis can be useful for this.

NOTE: As a software crafter, you should also "fight" when needed so that quality is taken into consideration and is part of the project planning, just like other considerations. For instance, if there are code improvements/cleanups to take care of, then you should justify and defend those. Never remain silent about quality and security risks.

One way to help end users to realize that quality is not perfect yet is to make the user interface less polished. The idea is that if you deliver a top-notch user interface, then users will feel like they've received complete & high-quality software, independently of what's under the hood.

References:

SWOT analysis
Tradable quality hypothesis by Martin Fowler
Principles of Quality Costs, Implementation, and Use by Jack Campanella

Conclusion

In this article, I've quickly explored the different tradeoffs around software quality and user satisfaction. It's a tough debate because reality is complex, and each situation is specific. My main point is that you shouldn't always just cut corners and lower the quality of your work just to meet deadlines. Sometimes it's better to stand up, analyze the pros and cons, the risks involved, and help your customers make decisions that they won't regret later on.

What is your opinion about this topic? How do you deal with pressure to deliver and the tension it creates?

That’s it for today!

PS: If you want to learn tons of other cool things about product/software/Web development, then check out the Dev Concepts e-books, subscribe to my newsletter, and come say hi on Twitter!

An online community for Software Crafters

Sébastien D. — Wed, 25 Aug 2021 13:02:54 +0000

There's now an online community dedicated to Software Crafters.

One more community? Why?

I've decided to create an online community for Software Crafters. Here's what it's all about!

There are countless communities out there, on Slack, Discord, Reddit, etc. But I don't think that there are many dedicated to people who consider themselves as "artisans of code".

I want to create that space because I'm sure that I'm not alone and that many people share the same passion for IT and Software Development.

Considering IT & software development as a craft doesn't mean focusing on code quality more than business outcomes, on the contrary. But it does mean not losing sight of technical debt, and the risks/costs it incurs.

How to join?

If you think of yourself as a crafter, then come join us on Slack, where we'll discuss best practices around code quality, testing, security, software design, IT architecture, and more!

Here's the invite link: https://join.slack.com/t/softwarecrafterstalk/shared_invite/zt-umgx3v06-4rtJ20PXz867GTPzCk1zeQ

PS: If you want to learn tons of other cool things about product/software/Web development, then check out the Dev Concepts series, subscribe to my newsletter, and come say hi on Twitter!

What is a software crafter?

Sébastien D. — Wed, 18 Aug 2021 15:23:53 +0000

Even if we use terms such as software engineering and software architecture, software development is really much more of an art form than a science.

This content is part of the first volume of my Dev Concepts series of books.

What is a Software Crafter?

Simply put, the software craft is about more than just software development and software engineering:

After 15+ years in the field, software development feels much more like an art than like a science to me. In IT, each problem has an almost infinite number of solutions. Some are better than others, and it takes experience to know. To me, that's the fun part of the job. Every day is filled with new interesting puzzles to solve. It can be frustrating at times, but when approached with the right mindset, it can be a real pleasure.

I personally consider myself as a software crafter. Much more so than as a software developer/engineer. The word craft has a very profound meaning for me.

I consider it as a combination of the following definitions:

Skill in planning, making, or executing
Make or produce with care, skill, or ingenuity

As a crafter, I don't just want to be a coder, generating endless lines of meaningless code. I don't want to be a generator of one-line wizardry that nobody can understand. Writing working software is simply not enough.

I don't want to deliver solutions that are very costly or even impossible to maintain. I don't want to create solutions that don't deliver real value to their users. Collaborating with customers is not enough for me.

That is why I've signed the Manifest for Software Craftsmanship, along with at least 30K other crafters.

What I want is to be a professional, part of a community of professionals. What I want is to craft beautiful code that stands the test of time. I want to help raise the bar higher for everyone. I also want to help others learn the craft. Finally, I want to build partnerships with my customers, so that I can continually bring value to them. If you're familiar with the Agile Manifesto, then I would say that I value the craft over simple "execution". I've called my company DeveloPassion precisely because I have a passion for software development and want to leverage that passion to build great software for my customers.

Your work is craft, and if you hone your ability and apply it with respect and care, then like the skilled wheelwright you can generate meaning in the daily efforts of your professional life. Cal Newport, Deep Work

Creating what I consider to be well-crafted (or beautiful) code/software requires careful thought and attention, which in turn requires sharp skills. Developers that don't consider software development as a craft won't put in the efforts required to fully grasp what they're doing and will be satisfied with much lower quality results.

Considering software development/engineering as a craft has an important impact on what you want to deliver: not only value, but also quality, maintainability, beauty, and even elegance. Beautiful/high-quality software is multi-faceted, as I explain in Dev Concepts. Approaching software development as a craft also deeply influences the pride that you can feel in your work.

I want to encourage each and every single one of you to really consider software development/engineering as a craft rather than as a "production" job, and to raise the bar higher by aiming for quality over quantity. Crafters should also be able to communicate effectively with customers, and subject matter experts. Professionals understand that strong communication skills are paramount for success. It's not only a question of execution! The net results will be happier customers, less costly developments, and pride for achieving great results.

Becoming a software crafter is not easy. In the next articles, I'll tell you everything I know about how to become one. It takes time and effort, but you can aim to become one on the very first day; simply by truly caring. Caring not only for the end result, but for everything in and around the development (i.e., tooling, methodology, approach, collaboration, documentation, etc).

References

Manifesto for Software Craftsmanship
The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt
Software Craftsmanship: The New Imperative by Mike Hendrickson
The Craftsman by Richard Sennett
Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoove and Adewale Oshineye
What is Software Craftsmanship
Craftsmanship - the Fifth Agile Manifesto Value?
What happened to Software Craftsmanship

Conclusion

In this article, I've tried to share my vision of what it means to be a software crafter. It means different things to different people, but there's a core element to it: the constant focus on going above and beyond, and improving constantly.

You can approach software development as a job, like any other, something that brings food on the table. At that's fine, really. But approaching this job as a craft will help you achieve better results, and take pride in your work.

What is your opinion about this topic? Are you also a software crafter? Do you want to become one?

That’s it for today!

PS: If you want to learn tons of other cool things about product/software/Web development, then check out the Dev Concepts series, subscribe to my newsletter, and come say hi on Twitter!

How to get started in IT and grow as a Software developer

Sébastien D. — Sat, 14 Aug 2021 12:27:19 +0000

In this article, I'll quickly describe a path that you can follow in order to discover/learn IT and Software development from scratch. I'll also discuss the different career paths that you can explore over time, based on your own interests and goals.

This content is part of the first volume of my Dev Concepts series.

Overview

Let's start by taking a look at a simple overview of the different sub-domains of IT and software development that you can explore over the course of your career. There's more, but those are front and center:

As you can see, there's quite a lot. Enough actually to keep you busy and learning for a whole lifetime. The above diagram puts more emphasis on the Software Development part, which is why it is bigger. But rest assured that the other domains are as important, and at least as wide. You could in fact spend your whole career in any of those "sub-domains" of IT, and you would still be learning new things every single day.

There's actually so much complexity and variety in IT that each of the sub-domains includes various job types. You could become a security specialist, focused on pentesting, or a malware specialist, a hardware hacker, a cloud security expert, an IT auditor, etc. Or you could work in IT architecture, and become a software architect, an infrastructure architect, a solution architect or even an enterprise architect. It's the same for most domains, really! This is actually one of the things that I enjoy the most about IT. There's so much to learn and do that you will never get bored.

It can feel daunting at first, but don't be scared. You can start small, learn the basics, grow at your own pace, and finally reach your dream job.

Where should I start?

If you're just getting started with IT and Software development, then you should focus on a few core topics at first:

Computer architecture
Operating systems
Coding basics
General concerns (e.g., code quality and testing)

Your goal shouldn't be to become an expert right away, but rather to get a bird's eye view over IT before diving into more specific subjects like front-end or back-end development. Many tutorials on the Web will immediately teach you about HTML, CSS and JavaScript, without helping you to see the bigger picture. Of course, you can take shortcuts to accelerate learning, but if you lack fundamental knowledge, then you'll have a hard time becoming a software crafter, and you'll have difficulties further down the road.

NOTE: You should get into the mindset of a software crafter right from the get go. Try to discover, understand and follow best practices.

Where do I go from there?

In the beginning, whether you choose to explore back-end or front-end development doesn't matter all that much. If you know which side you prefer to work in, then it's easier indeed, but both are as complex and as difficult to learn. They each have their specificities and attention points. Over time, if you're motivated enough, then you should jump over the fence and discover the other part. You might even try to go full-stack from the very beginning, but it'll probably take you more time to become really productive. The good news is that there is a lot of overlap between back-end and front-end development.

Whichever path you choose, security must always be on your mind. It isn't an option. Security is a top priority, whether you, your team, team leader and/or organization realize it or not.

As you gain confidence/understanding of the basics, you'll be able to dive into software design to improve the quality of your code, and help it stand the test of time.

After a while, you should get (at least) a basic understanding of software architecture. Ideally, you should also learn more about solution architecture and enterprise architecture, as those are really impactful areas of the software world (especially so in larger organizations).

TIP: Don't worry about the time it all takes. This is a journey. Not a sprint, but rather a marathon. Take your time and move forward, one step at a time.

Another idea is to dive deeper into the functional or even business analysis sides to become a better partner for the end-users. As I've mentioned in my previous article, depending on the organization you work in, you might have more or less opportunity (or need) to do this.

Furthermore, growing more knowledgeable about IT infrastructure/operations, cloud computing and DevSecOps will help you to contribute to the full spectrum of the application life cycle. Knowing how a system is deployed, how the infrastructure is configured is very useful and people who want to get into technical leadership clearly need to understand that. I've personally decided to work for a few years in IT infrastructure so that I could dive much deeper into that area. Believe me, I've learned a ton. It was definitely challenging, but it was also super fun.

You may also try to learn what you can about team/project/process management. Team organization is a fascinating subject in and of itself. Knowing about team/product/project management is incredibly useful, whether you're in charge or not. Most software is developed by teams made of humans, and the team dynamics have a huge impact on what the team is able to deliver. Product management is also a very interesting area, where having a background in IT can help a lot.

One thing to avoid is doing the exact same job for too long (unless it remains interesting/engaging/fun), because you'll stagnate, and you won't be challenged enough to learn new things. The same goes for staying on a legacy technical stack for too long, which can keep you too far away from the current job market, and make it much harder for you to find a new job. It's common knowledge that you should always expand your comfort zone. It's the only way forward in life ;-)

One can choose to go back toward safety or forward toward growth. Growth must be chosen again and again; fear must be overcome again and again. (Abraham Maslow)

All of these steps can take you in various directions over time. You could become a software developer, a technical leader, a team manager, a front-end specialist, a business analyst, a security specialist, an IT architect, or even a Chief Technical Officer (CTO) if that's what you fancy. The possibilities are endless. You could also decide to specialize in a very specific niche domain. It's not my preference, but it's all up to you... and that's the cool part!

The notion of seniority is also of interest, but is really relative; it means different things to different people. Some people/organizations consider that seniority equals number of years, while that couldn't be further from the truth. To me, seniority is about both knowledge, and experience. Both take time to acquire of course, but with motivation and dedication, one can learn much faster. Time alone is an awful indicator of seniority.

Finally, independently of your evolution within the world of software development, you'll also have to choose between being an employee, a consultant, a freelancer, or even a mix of those. For instance, I'm currently a freelance IT coach/CTO and a part-time employee. One benefit of being a consultant/freelancer is that you'll have to learn much faster; there's no choice, otherwise you won't be able to find/satisfy clients. You'll also get to discover various environments, teams and company cultures. Those experiences can help you grow much faster.

Don't hesitate to revisit your choice over time too; what's true for you today might not be tomorrow, and change can be wonderful, and refreshing!

Conclusion

In this article, I've told you about possible career paths in IT and software development. I've also given you a few pieces of advice about where to start, based on my own experience. Of course, this is just my opinion. I'm a generalist, not a specialist, so I see a lot of value in learning about many things. But being a specialist is also fine.

In any case, it's your own career, so make your own choices. Just keep in mind that not choosing is also a choice. No matter what you choose, make sure to have fun!

Come discuss on Twitter, and tell me about your own career choices!

That’s it for today!

PS: If you want to learn tons of other cool things about product/software/Web development, then check out the Dev Concepts series, subscribe to my newsletter, and come say hi on Twitter!

What is the difference between software developers, engineers, coders, and programmers

Sébastien D. — Tue, 03 Aug 2021 12:18:38 +0000

Now that we've clarified a bit what software development is and how software engineering differs, let's look at the difference between software developers, software engineers, coders, and programmers. Please note that this is a personal opinion, and depends on the context; there's no universal truth here.

This content is part of my Dev Concepts series.

Is there really any difference?

Let's answer a seemingly simple, but important question: what is a software developer, engineer, coder, programmer? Well, like many things in IT, the answer is "it depends".

Usually, I use those terms interchangeably, because I consider that all the people who write code should actually apply software engineering techniques. I'm not a big fan of the term "coder", because it gives the impression that code is all there is, and nothing could be farther away from the truth. It's doing more harm than good, even if the term sounds "cool". The same is true for the term "programmer".

Generally speaking, a software developer is someone who writes code and thus who creates software. Obviously, software developers need to know as much as possible about code and programming languages.

Then, depending on the context/environment (e.g., hobby, side-project, small/large team, small/big company, etc), developers have more or less responsibilities. The common denominator of course remains the coding part and everything that surrounds it directly (e.g., code quality, best practices, patterns, etc). As a software crafter, I consider that all software developers also need to test their code (ideally using automated tests), but I know environments where quality assurance and testing are kept separate from development (for better or worse).

In small startups, "developers" tend to take care of everything, and the kitchen sink. For instance, they'll take on requirements gathering, solution architecture, software design, coding, User Interface (UI) design, User Experience (UX) design, testing, release management, deployment, infrastructure, security, and so on. It's much more frequent to find so-called full-stack developers working for small startups.

In large teams/groups/organizations, there is a much more granular separation of roles and segregation of duties. There, you'll find business analysts (BAs), functional analysts (FAs), enterprise architects, solution architects, software architects, software developers, UX designers, UX architects, UI designers, Web designers, front-end developers, back-end developers, testers, security analysts and more!

As I've said, it depends.

Conclusion

In this short article, I've quickly discussed multiple terms that are often used interchangeably in the software development world. Software developer, engineer, coder, programmer, etc. What's in a name, right?

It's just an idea, a simple concept. And that's the magic; if you learn the concepts one by one, then you'll quickly become one of us, a software crafter. It's not that hard; it's like everything, it just takes time.

That’s it for today!

PS: If you want to learn tons of other cool things about product/software/Web development, then check out the Dev Concepts series, subscribe to my newsletter, and come say hi on Twitter!

What is software engineering

Sébastien D. — Thu, 29 Jul 2021 15:41:03 +0000

In this article, I'll share my personal take on the difference between software development and software engineering (SE). It is a personal opinion, so take it with a grain of salt.

This content is part of my Dev Concepts series.

So what is it about?

Many people may tell you that both terms refer to the same concept. Personally, I don't agree. The way I see things, software development is the "what" (i.e., the activity) and software engineering is broader; it corresponds to the "what" and the "how" (i.e., the process, the approaches, the methodologies, etc).

NOTE: Before going any further, I want to clearly state that the term "engineering" might be wrongly interpreted. Software engineering takes inspiration from engineering and tries to apply similar structured approaches to software development, but fundamentally, Software development/engineering is and will remain a creative endeavor. The software world is complex. Even if we try to apply engineering techniques to professionalize the way we work, it is hard to predict software development time, to provide verifiable proof that a piece of software does what it should be doing, etc.

I like the definition of the IEEE standards body:

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software (IEEE 610.12-1990)

To create software, we perform various activities, and how we approach those activities has a huge impact on the results and on the overall quality. Writing code is only a part of the story. There are many more activities around coding. For instance, before coding, we need to understand user needs (i.e., their requirements). Then, we need to clarify the business rules (e.g., is X accepted or not, when, how, why), the workflows (e.g., what happens before/after X), the data models (i.e., what concepts/data will the application manipulate), the data flows, etc. Still before coding, we also need to architect and design the solution so that it is built on solid grounds.

The coding part itself is also critical of course, and there are many dimensions/things to take care of. Security is also something of the utmost importance. Finally, once code has been written for an application, it needs to be built, tested/validated, released, deployed, monitored, maintained, etc. My Dev Concepts series as a whole discusses those topics.

Luckily, there's actually a generally accepted standard defining a set of phases for software development projects. It is called the Software/System Development Life Cycle (SDLC). Personally, I think that all software developers should clearly understand the SDLC and apply it in their projects, whether big or small.

Next to the software development phases, there are other things to consider like the software development approaches/methodologies (e.g., Agile, XP, etc) and project management techniques (e.g., PMBOK), which greatly impact the way we work, and collaborate with each other.

To finish this short post, I'll leave you with a wonderful quote from Margaret Hamilton, one of the pioneers of software engineering:

Software during the early days of this project was treated like a stepchild and not taken as seriously as other engineering disciplines, such as hardware engineering; and it was regarded as an art and as magic, not a science. I had always believed that both art and science were involved in its creation, but at that time most thought otherwise. Knowing this, I fought to bring the software legitimacy so that it (and those building it) would be given its due respect and thus I began to use the term “software engineering” to distinguish it from hardware and other kinds of engineering; yet, treat each type of engineering as part of the overall systems engineering process. When I first started using this phrase, it was considered to be quite amusing. It was an ongoing joke for a long time. They liked to kid me about my radical ideas. Software eventually and necessarily gained the same respect as any other discipline. (Margaret Hamilton, Lead software engineer of the Apollo Project)

References

The Mythical Man-Month: Essays on Software Engineering by Frederick Brooks. That book has deeply influenced me as a crafter
Software engineering @ Wikipedia
What is software engineering
Software engineering glossary: IEEE Software Engineering glossary @ MIT
SDLC @ Wikipedia

Conclusion

In this short article, I've introduced the notion of software engineering. It's just an idea, a simple concept. And that's the magic; if you learn the concepts one by one, then you'll quickly become one of us, a software crafter. It's not that hard; it's like everything, it just takes time.

That’s it for today!

PS: If you want to learn tons of other cool things about product/software/Web development, then check out the Dev Concepts series, subscribe to my newsletter, and come say hi on Twitter!