I’ve recently stumbled upon this story posted by another member here on Medium:

In her story Asha Rani tells how she went from studying software development, moved to a job after graduating and eventually resigned. Here are the main pieces I’d like you to think about in more detail:

I realized that programming at work is very different from programming at school.

I remember spending countless hours on the W3Schools website learning and testing new fun things.

I just want to say that I still love coding. I still love my brainstorming sessions with the development team, but I think programming was just not the right fit for me. …

We need to rethink how we are teaching and learning programming.

Recent years have seen an explosion of new programming languages and platforms. Along with those, every few years a new generation of programmers is joining the community. Those new programmers read success stories, see a multitude of available tutorials, courses and how-tos and decide to join in, hoping that the available materials will help them reach the same level of success as their older colleagues were able to achieve.

And yet we are stuck. What exactly is happening?

We have an upcoming generation of developers who got completely engulfed in the tutorial culture. Developers who are experiencing high levels of anxiety due to impostor syndrome when they enter the job market. Developers not able to assess their own skill level and feel confident. Years spent learning should not become something that we will look at with regret some day. Yet this seems to be more and more common when we keep telling that tutorials are the main source of knowledge. …

I would like to propose an important change to the way we teach Swift. The approach that is the most common currently has a flaw that may be locking the upcoming generation of Swift developers in the tutorial purgatory. They may not be able to level up as easily as they should.

And we, technical writers, may be at fault.

When we are writing tutorials, guides and how-tos, we may be forming bad habits and not forming good habits instead. We are teaching developers how to do things, but we aren’t teaching them how those things should actually be done in production-ready code. By necessity, tutorials take shortcuts. …

WordPress attracts developers by allowing anyone to participate in the ecosystem by creating plugins and themes. There aren’t any systems in place that would assure that the quality of the add-on software meets any guidelines. This is both great, as it allows people with little experience in programming to create new solutions, but it’s also a curse for the community at the same time, as it allows lowest quality code to enter the system.

Don’t get me wrong, I love WordPress and I’ve been participating and working with WordPress-related software for the last 10 years or so now. I’ve seen it grow from a basic blogging platform to the fully-fledged, multi purpose CMS it currently is. I remember the times when it didn’t have custom post types yet, only posts and pages. …

In this story I’d like to talk about something nobody ever talks about, every tutorial just simply skips, and basically everyone takes for granted without giving it a second thought.

I do think, however, that to become better at Swift programming, at some point you need to start with the most basic ideas and go up from there. You can break this pattern at the beginning to dive in as quickly as possible and start creating code, but there comes a point where you want to move into more professional level and return to the basics.

At this levelling-up point you start to think not only about how to use the language to create software, you also start to think about how the language itself works, what it means when you write something, what the parser and compiler do with the plaintext source files to turn those into executable code and take advantage of that knowledge to write even better code. …

On November 18th, 2019, my first iOS app was accepted by the App Store reviewers to be available for download. To say the least, I was in heaven! I wanted to do that for years now. I’m someone who fell in love with the idea as soon as I checked out the first generation iPhone back in 2008.

It’s been a year now, so it’s time to look back and compare where I was then and where I’m now. A kind of postmortem.

I’ve certainly learned a few things over the year that I wished I have known earlier. …

Here is a list of four fun reasons you should avoid using data types such as Int and String to pass along and process the data in your Swift code. And a list of alternatives to use instead, so you can write much better code with just a few small changes to your current habits.

Note: I’ll troll around a bit because technical articles can be boring.

Note that I use the word Fun in a slightly sarcastic way, as in: “Losing is Fun”.

1. Primitive types aren’t documenting your code

When you see a function definition like this one, do you instantly know what both of the String will actually be? …

Until recently, it was a matter of searching on GitHub for interesting packages you could use in your Swift project. You can do a few Google searches and it’s possible you will find what you were looking for. But now, it’s become even easier as we have the Swift Package Index available.

As Apple didn’t take care of creating a central repository or a search engine for discovering Swift packages, two developers (Dave Verwer and Sven A. Schmidt) — and a number of contributors — helped to make the process much simpler.

Check it out for yourself at https://swiftpackageindex.com!

Apple is planning to create a package registry, but the Swift Package Index is much more than a list of available packages — it’s a search engine. …