Show newer

Note to pretty-much everyone. If you have an iPhone 13 you really don't need to upgrade to an iPhone 14. You're welcome.

I recently rewatched the film Speed (1994), which in addition to being highly entertaining, inspired me to write an approachable yet action-packed tutorial for learning test-driven development with Python and PyTest library.

After reading, you have learned how to split a list of requirements into small, automatically testable and deliverable slices. In the end, we refactor the logic from crude but working to elegant and working.

How do you design your frontend application with tests? I have my trusted way, but now I'm interested in learning about yours.

Remember, friends: when cooking, you measure garlic with your heart.



via @HTHR

There is no better way to learn a topic than to write about it.

Yes, sometimes I might write something you see as objectively wrong, but you are also more than welcome to discuss it with me, given that you do it professionally.

That way, we both will learn from it.

Thank you for listening to my TED talk!

Show thread

Advice to anyone starting to write about tech: start with the easy topics to get hands-on writing experience.

When your professional experience grows — this may take years — move on to write about more complex and controversial topics.

Learn to handle criticism and leverage feedback to improve your thinking and writing.

Show thread

If we disregard the trolls and naysayers, what's left is very constructive feedback — whether in agreement or disagreement — amplifying your learning to new levels.

You cannot achieve those levels when writing about easy topics.

Show thread

On the hard path, a writer's life is a bumpy road of ups and downs. Both support and criticism will be overwhelming in amount and intensity.

Some people will even go so far as to renounce you as a unicorn developer spellcasting imaginary software in a fantasy land that has nothing to do with the real world.

Others will blindly renounce you as a cultist chanting mantras.

Show thread

On the easy path, a writer's life is simple and enjoyable. People engage with you, mostly agree with your content, offer better advice, and encourage you to write more.

Then you go and write more listicles — an excellent approach for many.

However, as a writer, I find it hopelessly dull.

Show thread

A writer choosing the hard path focuses on ways of working, fundamental engineering practices, and other broad concepts.

Typically they share content about test-driven development, pair/mob programming, technical/business agility, patterns for writing clean code, refactoring, domain modelling, software architecture, and last but not least, tips for boosting your career.

Show thread

A writer choosing the easy path focuses on programming languages, frameworks, and general coding tips.

Typically they share listicles such as "Top 10 Frontend Libraries You Must Know", hands-on pieces like "How to Work With React's useEffect Hook", and tutorials like "Building Todo MVC with Ruby on Rails".

Show thread

Generally speaking, there are at least two paths to take when writing about software engineering: the easy and the hard.

Well, that was an obvious take, huh? So let's dig deeper (thread continues).

Fair enough.

Sometimes it's possible even to offer them a job.

However, our industry needs more engineers and problem finders than developers and problem solvers.

Show thread

It's also important to note that you can be a senior developer when you learn to write outstanding code.

Senior engineers then excel in providing outstanding business value to their company and clients with or without developing software.

There's nothing terrible about being a developer. I've interviewed many candidates who have stated they would only write code and drop everything else given the opportunity.

Show thread

On the other hand, software engineers bring forth broader value.

They produce solutions, but they also actively participate in finding the problems needing those solutions.

They produce more than code but engage in discussions with stakeholders and businesses regarding the best way forward.

They also help with support operations such as sales, marketing, and recruitment. A common question a software engineer asks is, "Why should we implement this?".

Show thread

For me, a software developer is someone skilled enough to produce technical solutions individually and with the help of a close team.

Their work, unsurprisingly, revolves heavily around developing solutions with code.

They are often the "ticket crunchers" who accept specifications and produce quality solutions satisfying those specifications.

A common question developers ask is, "How should I implement this?".

Show thread

What distinguishes a software developer from a software engineer?

At first, these might sound like simple titles, but they carry more than semantics.

When I work in pairs, my pair doesn't allow me first to produce an insufficient solution.

We immediately start the discussion and promptly end up with an architecturally saner solution in the above scenario.

However, I wasn't nearly that productive. I might have been watching my pair do all the "work" while I sip coffee. I probably should be fired.

Which approach do you think has more noise than signal?

Show thread
Show older
Mastodon for Tech Folks is shutting down by the end of 2022. Please migrate your data immediately. This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!