Categories
Community

From Interpreted Basic to Swift UI – Part 2

From Interpreted Basic to Swift UI

Developer Nation Community Stories

Part 2

Check out Deborah’s story as it started out here

Week of WWDC 2022 

Monday – Mapping down the journey

Apple’s WorldWide Developers Conference (WWDC) for 2022 kicked off with the Keynote (1 hour and 48 minutes) where I sat and enjoyed the presentation and did not take any notes. The Platforms State of the Union sessions (1 hour 10 minutes) was next, after an hour for lunch on the West Coast. This also is a session I watch and do not take notes. They also had the Apple Design Awards (18 minutes) and a Day 1 recap (3 minutes).

During the week, I looked over the list of sessions available each day and jotted down the ones that I was most interested in, listed by the days the videos would be available. I figured I would start with those and potentially watch others based on what I learned from the first set and how much energy I had left from the day.

Tuesday – The Swift Cookbook of Navigation 

On June 7, I was ambitiously planning on watching the following sessions, once they because available that day:

  • Build Your First App in Swift Playgrounds
  • Dive into App Intents
  • Get to Know Developer Mode
  • Implement App Shortcuts with App Intents
  • The SwiftUI Cookbook for Navigation
  • What’s New in SwiftUI

I opened a Word document and copied the transcript of each session and any code that was attached and pasted it into the document. I figured it might come in handy to look for terms, ideas, or code snippets someday. 

The first session, Build Your First App in Swift Playgrounds, was interesting, and I do not have a lot of hand-written notes about it, as it did not directly apply to my goal, to learn how to use SwiftUI to update my way-out-of-date-app. 

The second one, Dive into App Intents sounded promising and yet…it was about how to make it easier for a user to RUN your app, not how to describe what I intended it to do for me. I took lots of notes from Implement App Shortcuts with App Intents because I was determined to make them work for me somehow. 

Now, the SwiftUI Cookbook for Navigation was exactly what I needed. It talked about three-column navigation split view, and showed Recipe Categories, Recipe List, and Recipe Detail. This would work fine for me. I need to implement this! Yippee! I found what I came for! 

Now, I just needed to dig deeper and find out how to implement what they were cooking up! It talked about new container types: NavigationStack and NavigationSplitView. 

I did not watch the last session I had planned for Monday. I saved that for Tuesday morning, as the new sessions were not available when I get up early (I live on the East Coast of the United States and Apple and their timeline is based on their West Coast location) and I wanted to have something to do so I wasn’t tempted to log into my full-time job and check on some things. This was my “vacation” week after all. 

Wednesday- Design App Shortcuts & Privacy Nutrition Label

On June 8, I added to the one left-over session with the following choices:

  • Create Your Privacy Nutrition Label
  • Design App Shortcuts

Swift UI & Swift Charts 

I started with What’s New in Swift UI from Monday’s list. It was a list of sessions that talk about the details of new items in SwiftUI, such as The SwiftUI Cookbook for Navigation, which was the last session I watched the previous day, so I congratulated myself on that choice. 

The session also mentioned Swift Charts, and this was not of interest to me because I had no immediate plans to add charts to my app. It then talked about sharing, and since this is broken in my app currently, it peaked my interest until they talked about Mail, Messages, Air Drop, Notes, Add to Photos etc and  not  Facebook or Twitter, that are not not considered sharing now. The session ended with a peek at layout and how a mixed layout can be achieved with Grid, GridRow and GridColumn. 

Create your Privacy Nutrition Label

Next up was Create Your Privacy Nutrition Label. I went into this thinking there was an actual label that would need to be filled out to submit an app to the store. The areas are Data Used to Track You, Data Linked to You, Data Not Linked to You, and Data Not Collected. If the developer selects the last one, the label reads, “This developer does not collect any data from this app” and that applies to my app. So, that was all I really needed from this session.

Thursday – What’s new in Xcode

On June 9, I added just two more to my original list:

  • What’s New in AppStore Connect
  • Writing for Interfaces

I still have not watched either of those sessions. I started the day with What’s New in Xcode which gave me a list of other sessions to take a look at when I have time. Some new code was introduced and hints and tricks were shared to make coding faster by using code completion and using simple icons in a single size instead of needing all the sizes for all the different versions of pixel count now available. 

The new sessions I added to the watch list are:

  • Use XCode to Build a Multiplatform App
  • Meet Swift Package Plans
  • Create Swift Package Plugins
  • Building Global Apps: Localization by Example

Localization do or don’t?

I decided to watch the last one on that list first, Building Global Apps: Localization by Example. This sounded promising, and I was interested in how well the translation would work for my app. I thought it was  too much AI and not enough about how you will need to hire translators who would take the text you send them and return it in different languages, which you reference in code to use the localized version of the text. 

My small little app is not going to be translated. Not for this next version. 

Custom Layouts and Swift Playground 

Next, I watched the session Compose Custom Layouts with SwiftUI and learned about grids and geometry reader and the layout engine. It was way over my head, and not really relevant to what I was hoping I needed to do. I thought  starting in Swift Playgrounds is where I should turn my attention. I watched Create Engaging Content for Swift Playground only to find out that this was not relevant either since it was about how to write an app for learners.It was interesting though!

Friday  – Having a Design Lab appointment 

I had signed up for a Design Lab appointment so someone from the Apple Design department would take a look at my app currently available and make suggestions on how to improve it and bring it up-to-date. I took lots of notes on what he found when he used the app, and I have a few things to think about when re-designing the app that I hope to incorporate into the final product. Then, as I was looking around for sessions to watch, I noticed that my all-time favorite SwiftUI online instructor, Paul Hudson (@twostraws) had recorded a session at Apple Headquarters in their new developer lab podcast space so I just had to watch it. It was What’s New in SwiftUI for iOS16 and this is the session I took the most notes from and, as usual, after watching his session, I wanted to jump right in and start coding. 

Well, WWDC is over for the year. There are still sessions I would like to watch…you know, that magical time we all have called “someday”. It is time to get the app updated and into the app store before the time runs out and Apple pulls it from the App Store. That story was in part 1 and documents now I spent most of my Saturday after WWDC, all psyched up to get going with this new-found knowledge and enthusiasm for a redesigned version of my personality test app (Which 1 Are You). 

Sunday

After spending way too much time on Saturday downloading the Beta version of Xcode, making sure the app works, and then finding out I can’t submit to the App Store from Beta, and all the other pitfalls I tripped over, I was not too enthusiastic about redesigning the app. So, I reread some of my notes, and remembered that I had had a dream over night about how exactly I could do this.

 I started a new project in XCode, called TestingCode. To use as a proof of concept It has three structs, some state variables, and the body consists of a NavigationSplitView from the Cookbook session and Paul’s podcast. I thought I had understood it, and yet I cannot get it to work. And it’s back to my full-time job, too!

Coming up next : Debugging, NagivationSplitView and more

And that is where this blog ends, for now. Tune in for part 3, where I debug the issue, and learn more about this intriguing NavigationSplitView and how it actually should work. This is where the transcripts and code samples from the sessions I copied should come in handy to see what the pieces of the NavigationSplitView actually should be and how they work together.

Any comments? Suggestions? Email me at FromInterpretedBasicToSwiftUI@gmail.com.

Categories
Tips

Tips for Choosing a Programming Language for your IT Career & Projects

Tips for choosing

Choosing a programming language can be complicated as many aspects need consideration. You might wish it was as easy as choosing between various flavors of ice cream or pizza. Ask any developer or technical manager to understand what drives popular choices in the tech world. In this article, you can learn what drives a choice of programming languages and the data-driven decisions developers should take to safeguard their careers while ensuring success in the projects they deliver.

Technology changes rapidly in today’s digital race, and the chosen language must get future potential to remain in use with strong developer communities, or else organizations can face maintenance and integration issues. Even young developers are keen to know which languages have excellent career potential, so they invest their time wisely.

Young developers may make the mistake of choosing a programming language because it’s trendy and cool. As a young developer, you can avoid these mistakes by referring to various tech forums and authentic sources like Slashdata’s – 22nd edition of The State of the Developer Nation (Q1 2022) that offer insights into popular programming languages and their growth trends.

Choosing a programming language

The choice of a programming language gets intertwined between your career aspirations and work experience. You learn a programming language and need to work on projects to gain relevant industry experience. So as a developer, you need to have a holistic approach to choosing a suitable language.

Choosing a programming language depends on various factors, and you should know all the components to get a better view and then make a choice. A good selection of programming languages will lead to spending less time on scaling, maintenance, and other aspects like security in projects.

Here are some typical questions you must ask when choosing a programming language for a project.

  • Does the programming language have proper community ecosystem support? Is it going to work over the long term? Is vendor support available?
  • What is the type of environment for the project – web solution, mobile, cross-platform, etc.?
  • Are there any infrastructure considerations like new hardware or particular deployment needs?
  • What do the clients prefer?
  • Are there any specific requirements for the programming language’s libraries, tools, or features?
  • Are experienced developers available for the programming language?
  • Are there any performance considerations, and can the language accommodate this performance?
  • Is there a security consideration or requirement for any third-party tool?

It would help if you remembered that irrespective of the chosen programming language, you can write good or bad code with any language. Besides the typical questions above, it’s advisable to consider a few critical factors in-depth before choosing a programming language. In programming, adherence to widely accepted design principles and philosophies is essential.

Some critical considerations driving the choice of a language include the following:

1. Type of application

The type of application varies from complicated embedded firmware to web and mobile. Common programming languages like Java, Python, JavaScript and C# can build different types of applications on various platforms. There are also situations where specific languages work better. With the rise in mobile apps, for example, you would choose Java for building a native Android app or a C and C++ combination for an embedded firmware project.

2. Complexity of applications

Identifying the application’s size and complexity helps determine the choice of programming language. The smaller and simple applications like marketing websites or webforms can use content management systems (CMS) like WordPress that may need minimal programing. On the other hand, complex applications like e-commerce websites or enterprise applications or emerging technology applications like IoT devices or AI-based applications may require Java or C#. As a technical manager, you can be an expert in gauging complexity with various experiences.

3. Organization culture

The choice of Open source technologies vs. proprietary software tends to rest with the organization’s culture and a direction often set by management. All programming languages have a trade-off, and some companies may choose one that is scalable, while others may pick one that has a shorter learning curve and is easy for the developers. Whatever the culture, the priority should be on choosing a language that optimally addresses the project needs. You can easily understand an organization’s choice once you start working on their technology stack.

4. Time to market:

Businesses rely on getting their product to the market early for competitive gains. Choosing new programming technologies and languages is better for a project with longer timelines. You can complete your project faster by leveraging the developers’ existing skills. For example, if you already have an AWS-based cloud environment and relevant team expertise, it will be quicker to work on it than move to another technology environment.

5. Maintainability

Technology stacks have their library ecosystems and vendor support. Choose a programming language with regular update releases that will stay current for some time. Maintaining the codebase is essential, and maintenance costs depend on the availability of developers. For example, as per today’s trends hiring Java, C#, Python, or PHP developers is easy and cost-effective. Organizations can make a data-driven decision by looking at the size of programming language communities from various industry reports from Slashdata.

6. Scalability, performance, and security:

The performance of the application depends on your choice of programming languages. It becomes essential when the development environment has limitations on scaling. Some popular tech stacks with great scalability include Ruby on Rails (RoR), .NET, Java Spring, LAMP, and MEAN.

It would be best if you protected applications from cyber threats. Following the security guidelines are crucial before choosing any programming language for your application. For example, a financial application needs PCI compliance, while healthcare-related applications need HIPAA compliance. Your choice of programming languages must be able to deliver application compliance.

Insights – Slashdata – 22nd edition of The State of the Developer Nation (Q1 2022)

You know the factors that drive the choice of programming languages. Let us look at findings from the Slashdata – 22nd edition of The State of the Developer Nation (Q1 2022). It offers exciting statistics that can help you as a developer know if your skills are up to date or need an upgrade.

JavaScript remains the most prominent language community, with close to 17.5M developers worldwide using it.

Python has remained the second most widely adopted language behind JavaScript, with the gap between the two largest communities gradually closing. Python now counts 15.7M users after adding 3.3M net new developers in the past six months alone.

The rise of data science and machine learning (ML) is an apparent factor in Python’s growing popularity. About 70% of ML developers and data scientists report using Python versus only 17% using R.

Java is one of the most critical general-purpose languages and the cornerstone of the Android app ecosystem. Although it has been around for over two decades, it is experiencing strong and steady growth. Nearly 5M developers have joined the Java community since 2021. 

Data shows that Java’s growth gets fueled by the usual suspects, i.e., backend and mobile development, and its rising adoption in AR/VR projects.

Wrapping up

We hope you have more clarity and data-driven insights in choosing programming languages for your career and projects. We encourage you to regularly read the whole SlashData – 22nd edition of The State of the Developer Nation (Q1 2022) report and stay updated on trending technologies.

Categories
Community

From Interpreted Basic to SwiftUI – Part 1

Rewriting my app to Swift Part 2

Developer Nation Community Stories

Part 1

It is with great excitement that we are now kicking off our new section of stories coming right from our Developer Nation community members.

Our first piece comes from Deborah Graham who recently attended Apple’s WWDC and decided to put her learnings from that experience into immediate action. 

This is the first part of Deborah’s story, recorded in her own vivid style.

Taking 250 pages of notes at Apple’s WWDC

Well, another WWDC (Apple’s WorldWide Developers Conference) has come and gone (week of June 6-10, 2022). I took a week off my regular, full-time job as a Finance BI Specialist (yeah, doesn’t really explain what I do, let’s say I work with Access, VBA, and SQL a lot and some source systems to get data into reports and SQL tables so others can create Tableau reports for employees to consume) to “attend” the conference and I watched 12 sessions(so far)  and a surprise video from my favorite Swift online teacher, Paul Hudson (@twostraws).

I took a lot of notes, and then created a Word document with the transcripts and code segments attached to the sessions. This Word document is over 250 pages already (and I have sessions I haven’t seen yet that will be added to the document). Why did I do that? It’s actually already come in handy…but let’s not get ahead of ourselves.

Rewriting my app to Swift

For starters: Using Xcode and Figma

Over the weekend, after the WorldWide Developers Conference concluded, I started working on getting my current, old app (written in Objective-C and hard to maintain and update) updated to reset the clock so the app would stay available in the App Store. It’s “Which 1 Are You”, if you are inclined to download it and see the “before” version as I work though re-writing it into Swift and using updated standards and design expectations. 

I downloaded the latest Beta version of Xcode to make sure the app would actually still run (if not, I had a LOT of work ahead of me to get this app updated before the deadline Apple set before they yanked it off the App Store due to not having updated it since June of 2017…yikes, it IS old!). 

I found out that I needed an App Store Icon (1024 by 1024). I wanted to find a free program to create an icon. A quick search found a video which suggested some paid programs and a free one called Figma. I figured that would work for me. I created the simplest icon I could. Luckily, it built and ran without changes. 

I figured I needed something different before I could submit to the App Store, so I marked it as working Upside down, too. I ran into a long list of issues during Archive and they were all small items.

Submitting to the App store

Then I ran into issues when submitting to the App Store. I found out that I could not submit an app from a Beta version of Xcode. So, it was back to the other version I had and tried again.

It seems, since I said I don’t collect data on users, the frameworks I used originally for ads, which no longer work, do collect (or might collect) data, so I either needed to revamp my statement or remove the frameworks. So, I removed the frameworks and tested it again. All was good. Back to submitting to the App Store. 

Then, I needed screenshots in all sorts of different sizes. Luckily, another search showed me that the Simulator Tool allows for screenshots. I spent an hour running the program in different device simulators to take screenshots and upload them to the App Store Connect page to get all the images I needed. 

It was late Sunday night when I finally got the green light that the app was in for review. I went to sleep wondering if the review would find anything else I needed to do. Woke up Monday and checked my email. My updated app was available on the App Store! Version 1.6.3 was a go! 

This means, I have some time to work on getting the app into Swift and taking the knowledge and advice I received at WWDC 2022 and re-vamping the app.

This blog will document the progress, insights, inspirations, and setbacks as I encounter them. Hope you enjoy the journey!

About the Author – Deborah Graham

Deborah Graham is a professional developer. She has over 20 years of experience with various programming languages. It all started while attending Community College to get an Associate degree in Electronics technology (hardware). One day, they delivered some Apple IIe computers to the computer room to keep the PDP-11s company. There was a pong-like game written in Interpreted Basic where the source code was available. She quickly figured out that by increasing her paddle to 99% of the goal area and the opponent’s to 1% and turning up the speed of the ball, it was a fun way to a win. One small change, one big difference. And a love of programming was born. When not in class, she could usually be found sitting at that Apple IIe and tweaking the program a little to see the changes. After graduating, she held several hardware-related jobs to match the degrees (two Associates: Electronics Technology and Computer Maintenance Technology, both hardware-based degrees), including Test Technician, Manager of the Test Department, Customer Support (where she created the Customer Support Newsletter that would collect errors in the hardware or documentation and send it out to the local sales and support reps to cut down on support calls to the home office) and then she went to the documentation department to correct all the errors and to create technical documentation with the hardware engineers. She was a Technical Writer for an automated testing machine manufacturer. The documentation software (this was WAY before Word) used LISP (now just Lisp) as the extension tool. The writing team found they needed/wanted to extend the documentation software to do things like index across all documents and spell-check all documents. Luckily, there was a class happening and she flew up to Montreal to attend the week-long class and the love of programming continued! When she got back, all sorts of extensions were created and shared with other users of the software. 

One day, during the yearly performance review and plan for next year, her manager said to get a promotion, she would need to get a bachelor’s degree. Didn’t matter in what, it was one of the requirements to move up in the company. So, she called the local state school and asked what degrees they offered. And BSCS (Bachelor of Science, Computer Science) was one of the choices. It was either that, or Nursing or Teaching. Easy choice!

Right before graduating (and being eligible for a promotion), she was laid off! But now, with a degree to go with her love of programming, she was hired by the documentation software provider as a technical writer. After that, she worked for an early browser-based distance learning provider as a technical writer. One Friday, the boss asked her if the online help she was writing in HTML could pop up when links where clicked instead of completing replacing the main help. Granted, that’s a no-brainer now…but this just wasn’t available in HTML at the time. On the way home, she went to the local bookstore, went to the Computer Science section, and checked the index on all the books to find one that would be of help. She bought the book, read it on Saturday and Sunday (yes, she reads programming books for fun!) and on Monday, she got into the office before the boss, coded up come JavaScript and when he walked in, she said, “like this?” and he was amazed. The thrill of writing some code and seeing the result is very motivating. She went on to teach a class called “JavaScript for Technical Writers” at various places. As she was creating the class and with a vacation scheduled, she emailed the author of her JavaScript book asking his permission to use the book and the sample code in her class, promising to give him credit for the code. When she received his okay, that started her habit of bringing a programming book to take on vacation with her to learn a new language. Some people may take a romance novel to read at the beach…she falls in love with a new programming language!

That leads to the list of the programming languages that she was used to professionally write code:

  • M/MUMPS/Caché ObjectScript
  • HTML
  • XML
  • ASP
  • Lisp
  • Pascal
  • Certified AES
  • Visual Basic/VBA
  • JavaScript
  • Postscript
  • PCL
  • Python
  • SQL

And some that she uses for her hobby

  • Objective-C
  • Swift

Which brings us to the hobby. One team she was on had a meeting habit of taking personality tests before the meeting and then declaring which one of something each team member was. Which flower are you? Which Major city? Which cartoon character? Each week, someone on the team would find an online test, and they would all take the test and report the results for the icebreaker at the start of the meeting. One week, she was looking for a test on which character from Scorpion (a television show about geniuses that solved problems for the US government each week and learned a little more about how to function in society with a help of their “normal” assistant and her genius son). Anyway, she could find tests on which genius, but not specifically about that show. When she mentioned this difficulty to the team manager, she was told to write one herself. Apple had just opened the AppStore to developers, so here was another opportunity to learn a new language. It took a few years of reading books, finding online classes on Objective-C, and finally getting an app into the AppStore. The CIO of her company mentioned it at a few All-Hands meetings, and he shared his test results. There are 15 tests available for a variety of TV, movies, cartoons, and general interest. If you are at all inclined, it is called “Which 1 Are You” and it has her name as the developer. 

As an Apple Developer, she is invited to attend Apple’s WWDC (World Wide Developers Conference). Before the pandemic, it was almost impossible to get tickets. Since the last few years have been online, it opened the gates and allowed anyone to participate. She has “attended” WWDC for two years in a row now and looks forward to attending them each year. She takes a week off from her full-time job as a SQL and VBA Programmer and soaks in the new information and the enthusiasm from the presenters and other attendees.

She was asked by Developer Nation to document her journey from WWDC 2022 to an updated version of the app, totally re-written in SwiftUI, into the AppStore. Follow along and see what works, what doesn’t work, and let’s see if she can get the app ready for version 2.0! You can email the author at  FromInterpretedBasicToSwiftUI@gmail.com. 

Categories
Tips

How To Make It As A New Blockchain Developer

Blockchain developer

Crypto, Blockchain and Web3 are buzzwords these days and while you might already hold some Bitcoin on Coinbase or Binance, you might also be wondering how you can move your career into this new industry as a developer.

Good blockchain developers are highly sought after and becoming an expert in these new technologies can bring you an exceptionally high income as well as job security.

It’s easy to google “How to become a blockchain developer” to find out what technical skills you will need and what programming languages you will have to learn. You will find lots of helpful information e.g. here and here. 

According to the latest State of the Developer Nation Report, blockchain applications, cryptocurrencies, and NFTs have the highest share of developers learning about them.

Blockchain developer - graph to show that blockchain apps, cryptocurrencies, and NFTs have the highest share of developers learning about them.

More specifically with regards to Cryptocurrencies, out of a sample of 13,939 developers, 50% stated they are interested in them, 34% said they are learning about them while 16 % have already adopted the technology. 

But what actually is Crypto, Blockchain and Web3? And – once you have the skills – how are you going to get your foot in the door and create long-term success? 

Ecosystem Education

If you are a complete newbie, I’d suggest educating yourself on the origins and philosophy of bitcoin and blockchain first, as well as the evolution of Web3. There are some great free courses that will give you a solid foundation and might help you find a niche to focus your efforts on. 

UnitMasters.org for example is an engaging 6-week course that will give you a good high-level overview of the Web3 ecosystem. It is very welcoming to participants from all walks of life and underrepresented backgrounds.

The free MOOC on Digital Currencies by the University of Nicosia, which is taught by prominent bitcoin educator Andreas Antonopoulos, is a great place to start if you really want to understand how bitcoin works and why it is here. 

Crypto Job Boards

There are a number of job boards dedicated to Web3, but simply submitting your CV has never been the best way to go about this, in my opinion. Nevertheless, it’s helpful to know about them, so here are a few you can check out: 

  1. Cryptojobslist.com
  2. Bitcoinerjobs.com
  3. pompcryptojobs.com
  4. offthechain.xyz
  5. hirevibes.io
  6. AngelList
  7. web3.career 
  8. dotjobs.net
  9. Braintrust

Building Your Network

The best positions are often filled before they make it to a job board, since candidates are being hired from within the network of the recruiter or the organization hiring. That’s why it is important to connect with others in the space. If the term “networking” makes you cringe or sounds like a chore to you, here are some easy ways to go about that: 

  1. Attend crypto meet-ups or blockchain conferences to learn about all the things that are being built in this space. You’ll be amazed what some teams are creating out there and you will surely find something that excites you, or sparks your own ideas.
  2. Join the online communities of the projects that you are most interested in. Most of them have a Discord community, which you can find on their websites. Start chatting with other developers in there who may be looking for team members and look out for vacancies in their announcement channels.

Start using some DApps (Decentralized Applications) – whether it’s a simple wallet to send and receive cryptocurrency or blogging platforms like Hive that allow you to earn cryptocurrency for your content. If you’re a gamer, check out games like Splinterlands or Axie Infinity. It’s easiest to start with something you already know. 

No matter what your background is, begin using Web3 apps so you gain personal experience as a user. This will help you learn about their challenges or short-comings and you can begin thinking about solutions for them – whether it is UX design or their token economy. You could begin contributing to their improvements, or you could join (or create) a team that will build something better.

Many people get hired by companies because they have proven their knowledge, engagement and contribution in their communities already.

Web3 projects don’t hire staff, they recruit members.

This goes not only for other stakeholders like customers, users, block producers and investors. Crypto projects are win-win-win communities. All stakeholders are equally important in their contributions to help the project succeed.

4. Join Hackathons and coding bootcamps. Stay in touch with the people you meet there. They might all end up in different projects, so this is a great way to build your professional network. 

5. Start creating content! Whether it’s your own blog, a Hive account, or your Github account. Begin creating a public track record of your thoughts or technical contributions to the space.

“Don’t trust. Verify.” This famous crypto slogan applies not only to the blockchain but also to you. Creating a verifiable track record is worth so much more than a fancy CV. Your track record will speak for itself and send projects your way, rather than you having to look for them. Project teams don’t care about your CV, they care about your proven experience and contributions to the industry.

6. Join a DAO and see how you can begin contributing. DAO’s – Decentralised Autonomous Organisations – are an essential part of the Web3 space and might just become the way we will all work and organize ourselves in the future. You can submit proposals and get your contributions funded by the DAO’s treasury, if your fellow DAO members vote for it. Check out LobsterDAO or HerDAO (for womxn developers) to get started. 

7. Check out Gitcoin where projects post small tasks that you can earn cryptocurrency for. It will help you build a track record, too.

Community Is The New Currency

Everything in the crypto and Web3 space revolves around communities. There is very little of the top down structures you may be used to. The value of crypto tokens comes from their community of developers and users, and you will also end up choosing your project by the community it already has, or the potential it has to create one. (Are they building something that you think will be adopted by a large number of people? Is it going to make a difference to anyone?)

Make Everyone Want To Work With You

You may be highly intelligent, but intellectual intelligence is not the only ingredient for success. You can be a genius, but it will be of little use if nobody likes working with you. 

Emotional intelligence is a highly important part in communities. Web3 is all about “we” rather than “me”. People like to surround themselves with people they like and get along with. Even though everyone can code from their bedroom or a hammock on a remote island these days – be kind, be agreeable, be generous in your communication with others. Online and offline. Be a team player. Be someone that CEO’s, investors and HR or customer service staff enjoy working with. 

Making interpersonal communication skills just as important as your technical skills will help you become a highly valued and sought-after contributor and create lasting success!

Already a developer interested in Blockchain? Take the Developer Nation survey, share your views on new technologies, tools or platforms for 2023 and shape the future of the Developer Ecosystem. You will get a virtual goody bag with free resources, plus a chance to win an iPhone 13, a Samsung Galaxy S22, Amazon vouchers and more. Start here

Anja Schuetz is an Operations Management Consultant who has worked for several crypto wallets and blockchain projects. She also mentors first-time crypto investors and helps newcomers move their careers into Web3. Learn more about Anja at https://linktr.ee/consciouscrypto

Categories
Community

[Live Updates] Prize Winners – 23rd Developer Nation Survey

Developer prize draw winners

The 23rd Developer Nation Survey is live and running full speed and we already have our first winners to announce! Those that were lucky enough to win one of our amazing prizes!

What are the Developer Nation Prize draws?

If you’re new to our prize draws: developers who take our surveys earn 100 points for every new survey completed, plus 10 points for providing their feedback about the survey. And in return they become eligible for benefits and rewards – you can see a full list here.

Now, this is a survey that covers many technologies and participants may choose to participate in different ways. Some of them are members of our Community as well – so they are entitled to additional prizes.

This is why we run several prize draws. In this blog we will be adding all prize winners from our prize draws, so keep an eye on it as it will be constantly updated.

48 hour prize draw

iPhone 13 developer prize draw winner

iPhone 13 – @FergusonTreash of Nigeria

Nintendo Switch developer prize winner

Nintendo Switch – @thienanh2009 of Vietnam

Week 1

$20 gift cards

$20 developer prize draw winners

@WismarR of USA “Thanks”

Dolapo of Nigeria

A. of Croatia

Seona of Australia “Thank you!”

Jeswin of Saudi Arabia “I’m excited to accept this kind gift from developernation. Kindly please help me if I face any issues in redeeming it.”

Eduardo of Uruguay

o**************7@g***l.c*m of Nigeria

c*************9@1*3.c*m of China

SitePoint Premium License

SitePoint premium license developer prize

a*********1@g***l.c*m of Belarus

@adamdevbone of Australia “Thanks so much!”

h**********1@g***l.com of India

State of AR/VR Survey Prize Draw – Week 1

$500 towards your AR/VR project

$500 towards your AR/VR project @JoshuaH47169834 of United States

SitePoint Premium License – Ricardo of Brazil

SitePoint Premium License – James of United States “I’m so happy”

Week 2

Xiaomi RedMi 11 5G developer prize draw winner

Xiaomi RedMi 11 5G – 李文君 of China

$1,000 towards the desktop set up of your choice - developer prize

$1,000 towards the desktop set up of your choice – @marcellusm2 of Brazil

$100 gift card – Neba of Cameroon “I’m really grateful for you choosing me as a winner???”

$50 gift cards

$50 gift cards - developer prize draw winners

Cyrus of United States “Thank you”

@theddiya of Nigeria “Thank you for it”

Emilian of Romania

n********l.g*****a@g***l.c*m of Portugal

@doddsy5544 of Australia

h*********d@g***l.c*m of Indonesia

z********i@f*****l.c*m of China

State of AR/VR Survey Prize Draw – Week 2

$30 gift cards

J of Canada

R of United Kingdom

Gajendran of India

Week 3

Nintendo Switch

Armeiro of United States “I am euphoric the first time I win something for sharing my ideas and my profession “

$20 gift cards

$20 gift cards for developers

h**.a*****@g****.c** of United States

m**********@m**.c** of South Africa

Rémy of Belgium

J of Spain

Hamilton of Australia

n********@g****.c** of Philippines

w*******@b************.w****.w*** of China

e*****.l*********@g****.c** of New Zealand

State of AR/VR Survey Prize Draw – Week 3

$20 gift cards

Ian of Canada

p********@i*****.c** of Greece

Muhammad Dinar Aulia Rahman of Indonesia

Week 4

Docker 12 Months Pro Plan

s*********@y****.c** of India

$100 gift cards

c**************@g****.c** of Mexico

Godwin of Nigeria

$50 gift cards

j****************@g****.c** of Philippines

d*********@g****.c** of Poland

s*****************@g****.c** of Colombia

$20 gift card

m***********@g****.c** of South Africa

State of AR/VR Survey Prize Draw – Week 4

Amazon Echo Dot 4th Generation

Joe of USA

Week 5

Tick Tick Premium License

j********************@g****.c** of Philippines

Amazon Echo Dot 4th Generation

Justin Revilleza of Philippines

$20 gift cards

t***************@g****.c** of South Africa

d***********@g****.c** of Philippines

4********@q*.c** of China

p************@g****.c** of Poland

j******@g****.c** of South Korea

State of AR/VR Survey Prize Draw – Week 5

$100 Gift Card

b********@g****.c** of South Africa

Week 6

Tick Tick Premium License

GSS of India

Pluralsight Skills Standard 2 Months Subscription

Pluralsight 2 months subscription prize

Nikilosa of Jakarta

Skillshare 3 Months Subscription

Skill share 3 months subscription prize

v*****.s*******@g****.c** of India

Notion Personal Pro License

Roman of Mexico

VIVO Black Height Adjustable 32 inch Standing Desk Converter

a******.1*.a******@g****.c** of Argentina

Smart Plug

s**********************@g****.c** of Colombia

$50 Gift Card

e*********@h******.c** of Mexico

e***************@g****.c** of Mexico

Jorge of Spain

2****************@g****.c** of India

$20 Gift Card

鈴木朋和 of Japan

$10 Spotfiy Voucher

t**************@g****.c** of Mexico

State of AR/VR Survey Prize Draw – Week 6

Apple Air Tag

s***************************@g****.c** of Brazil

$30 Gift Card

s*********@g****.c** of Greece

Week 7

Amazon Echo Dot 4th Generation

s***********@g****.c** of India

Apple Air Tag

j*********@h******.c** of South Africa

$100 Gift Card

Michal of Czech Republic

$20 Gift Card

1********@m******.c** of United States

i*************@g****.c** of India

Community Prize Draws

Developers with 801+ points

Devices:

Samsung Galaxy S22 – @mouseannoying of UK

iPhone 13 – Lynton of Belgium

$50 Udemy or Gumroad gift card

Paschal of Nigeria
Thomas of Singapore
Michael of United States
Panji of Singapore
Deepam of India
Víctor of Mexico
Adrian of Malta
Christopher of Philippines
R of Brazil

Swag

A of UK
Brad of USA
Charlie of Australia
A of Ukraine
Geoffrey of Canada
Ashley of UK
V of USA
Thomas of Cyprus
Richard of United Kingdom
Nicholas of Trinidad & Tobago
Dean of Australia
Laborde of USA
Brian of USA
Alexandre of Belgium
Jignesh of India
Daniel of United Kingdom
Mike of United Kingdom

$15 gift card

Jonathan of Australia
Brian of Canada
Michael of United States
James of USA
Léo of Sweden
Tsvetomir of Bulgaria
Ioannis of Greece
Mikael of France
Akhil of India
Matīss of Latvia
S of Germany
Bledi of Albania
Stefan of Germany
Rodney of Canada
Thassilo of Germany
Andrew of United States
Vitalii of Ukraine
Andrejs of Latvia

What happens now

We’ve reached out to winners directly by email. If you recognise your email address but believe you haven’t been contacted yet, you can contact us here.

We’re already on the hunt for prizes for our next global survey, so if you’re not a winner this time, there are more chances to win in our future surveys.

To ensure that you are notified when our next survey is live, sign up. Don’t forget to make sure the survey notification option is ticked.

Special Thanks

We could not have brought all these prizes to you without our sponsors Florin Pop, CertNexus and SitePoint for donating prizes to the survey! Also thanks to our goody bag sponsors Buildable, CodeGym, Coil, CertNexus, Florin Pop, Kamon, Kentico, Linode, and Manning Publications. Are you a company interested in giving away a prize to developers in our next survey? Get in touch!

Categories
Analysis Business

The Power of Innovation: Developers at the Forefront of Emerging Technologies

The Power of Innovation

Over the last couple of years the tech industry has experienced several waves of disruptive innovation with the introduction of self-driving cars or Metaverse. While these high-profile technologies steal the headlines, the hidden gems like AI-assisted programming hold the power to reshape the world. 

In the 22nd edition of our Developer Nation Survey, we have shared some valuable insights on how the landscape of emerging technologies is being shaped by one of the key players – developers. Read on and uncover some interesting truths about what the future of emerging technologies might look like!

  1. The adoption of AI-assisted software development is the third-highest of any other emerging technology

It’s immediately apparent that AI-assisted software development captures developers’ interest – the possible impacts on working practices, careers, and remuneration are especially salient to 67% of developers. This interest is not purely hypothetical or academic – 14% of engaged developers are actively working on AI-assisted software development, and adoption of this technology is the third-highest of any emerging technology. We can’t say for sure if developers are building or simply using these technologies, though, given their complexity and novel status, it’s likely that many of these adopters are using AI-assisted development as part of their workflow rather than actively developing the technology itself. 

We are already seeing the effects of low- and no-code tools on the democratisation of software development, and with 46% of developers reporting that they use such tools, they pervade beyond the citizen developer well into the professional realm. AI-assisted development is a logical addition for many developers looking to increase their development velocity, and indeed, we see that developers who do 75% or more of their development work using low- or no-code tools (20%) are four times as likely as those who don’t use them at all (4%) to be currently working on AI-assisted software development.

  1. Computer vision, robotics, and blockchain technologies command high levels of engagement though NFTs seems to be losing popularity

Further down the list, stalwarts such as computer vision, robotics, and blockchain (cryptocurrencies and other applications) command high levels of engagement amongst developers, though NFTs – another crypto-adjacent technology – has much lower engagement, with just 48% of developers working on, interested in, or learning about it. This said, the money-making potential of NFTs has not gone unnoticed by developers – 11% of those engaged report that they are currently working on the technology, making this a potentially profitable niche for those who do get involved. In fact, all three crypto-adjacent technologies have high adoption and learning rates – for each, at least 30% of engaged developers are actively learning about the technologies.

Blockchain technologies, including cryptocurrencies, have experienced the largest increase in engagement in the last 12 months, with interest in crypto currencies increasing by 14% and interest in non-crypto blockchain applications increasing by 15%, but adoption of this technology has stagnated, increasing by a single percentage point in the last 12 months

  1. The growth in adoption rates has stagnated but developers are expanding their interest horizons 

Interestingly, we see that, compared to the previous year, growth in adoption rates has stagnated across the board. Part of this is due to the changing landscape of emerging technologies that we track, but careful examination of the change in engagement rates shows that many more developers are becoming engaged with a wider range of emerging technologies. In fact, the absolute adoption rates (the proportion of all developers working on a technology) have remained largely unchanged in the past year – developers have widened their interests but this has not yet trickled down to their working practices. 

  1. Metaverse is experiencing one of the highest learning rates outside the blockchain/crypto space

The Metaverse is another technology that has recently garnered a lot of interest, bounding into the public eye in October – likely coinciding with Facebook’s name change to Meta. We see that a healthy 53% of developers are engaged with this technology, but adoption is low, at 9% of engaged developers. This is likely because the Metaverse is still being defined.

Becoming a ‘Metaverse developer’ is a perplexing journey as it combines several contributing hardware and software technologies – extended reality (XR), networking, graphics, optics, machine learning, and blockchain, to name a few – many of which have yet to reach maturity, lots of developers will be waiting to see what the future holds. Indeed, 28% of engaged developers say that they are currently learning about the Metaverse, one of the highest learning rates outside the crypto/blockchain space. Many of these developers are likely positioning themselves to make the most of a possibly lucrative new technology. 

Categories
Interviews

DevsInTransit #1: From Frontend Developer to Developer Advocate at Stream

DevsInTransit #1: From Frontend Developer to Developer Advocate at Stream

Introducing the DevsInTransit series. DevsInTransit is an interview series that highlights the stories of developers who successfully transitioned into other adjacent roles (e.g devrel, tech writers, managers, e.t.c).  Author bio: My name is Linda Ikecchukwu. I’m a frontend developer turned technical writer. When I’m not writing technical articles or documentation, I’m telling the stories of content creators in tech via #TechContentCreatorSeries or #DevsInTransit

For the first episode of #DevsInTransit, our guest is Dillion Megida. Dillion is currently a developer advocate at Stream and is based in the Netherlands. Before joining Stream as a developer advocate, Dillion used to be a frontend developer based in Nigeria. This is his story.

Hello Dillion, it’s nice to meet you. Please introduce yourself and tell us what you do.

My name is Dillion Megida, and I am a Developer Advocate at Stream, based in the Netherlands. My work at Stream is basically to create content that shows developers all the fantastic things they can do with our SDKs. This content can either be articles, demos, or videos. 

Asides from work, I also create content on my own platforms. I have a personal blog where I write about JavaScript, React, and tech in general. I also have a YouTube channel. On my YouTube channel, I make videos about my life, my career, the different things that have worked for me, mistakes I’ve made, and how I’ve been able to access the opportunities that I currently have. 

Before moving to the Netherlands, you lived in Nigeria. Could you tell me more about the move? What were the challenges you faced after moving?

Before moving to the Netherlands in December 2021, I was based in Kwara State, Nigeria. When I first moved here, my first challenge was the weather. Moving from an average of 30 degrees in Nigeria to an average of 1, 0, or -1 here was the biggest shock. I mean, I was told how cold it would be, yet, it was surprising. But, I have adjusted with time. Thankfully, we’re approaching summer here, so the temperature will be up to an average of 10 degrees. 

The second challenge I had was food. I’ve never really been the kind of person to experiment with new food. I just stick to what I know. Luckily, I found an African store not really far from my place. I go there, get Nigerian ingredients that I’m familiar with, and cook my own meals. But, I’m also trying out some of their own food, like the sandwiches and bread (sidenote: they eat a lot of bread here :)). 

My third challenge was in terms of communication with friends and family. I had to shift everything to social platforms like WhatsApp because international rates are not so friendly. 

And lastly, there’s the culture. I wouldn’t call it a challenge, but it was new. Ninety percent of the people I’ve met here have been insanely generally kind to me. It was scary (but in a good way). I would always wonder if they were so generous to me because they wanted something. 

One of my favorite things about this place though is the public transport system. It’s very organized. So, yeah, I’m four months here, and I’m loving it. 

Moving to another continent is such a big decision. Was it your company’s decision?

I had the option to either work remotely from Nigeria or move to the Netherlands. I decided to move to the Netherlands because it was an opportunity for me to try something new and experience a new perspective. 

Another thing that really motivated me was that I felt like I’ll be exposed to more opportunities here than in Nigeria. I could attend more conferences and make new friends.

Before becoming a developer advocate, you used to be a frontend developer. What caused you to change paths?

A year ago, I didn’t even know what dev advocacy was. However, what really made me want to leave my frontend role was that, as much as I loved frontend, I also wanted to create more content.

But, I didn’t have as many opportunities as I wanted as I am more focused on delivering updates and fixes to projects.

While searching for a role that embodied my interests, I found dev advocacy. I realized I was already unofficially doing what a developer advocate does. I still do frontend stuff in my current DevRel role, like when I’m creating a demo application, and I also get to create content — it’s truly the best of both worlds.

Dev advocacy is still a developing role, and across several companies, the expectations and responsibilities are not very defined. In some companies, dev advocates work with marketing. In others, they work with product or engineering. What is it like at your company?

Yeah. While applying for these DevRel roles, I saw that different companies had different requirements. I also have a friend who is a DevRel but doesn’t like the DevRel job at his company anymore because there are just so many things he’s asked to do. 

Thankfully, my company is quite a big organization. We have a marketing team that handles content, strategy, analytics, etc. Then we have eight people (me inclusive) on the DevRel team. Each DevRel person handles a different SDK platform like iOS, Android, or Swift.

For me, I handle creating content around our React SDK. So far, the content I create depends on the company’s plans and what I’m comfortable with. For example, the company’s plan might be to improve the YouTube channel, then we’ll work towards creative ideas that we can transform into videos. Other times it could be that we need more articles on a particular framework or SDK, then we focus on creative ideas that we can turn into articles. 

How did you prepare for your interviews? Did you make use of any specific resources?

To be honest, I didn’t use any specific resource. I mostly did a lot of research on who a DevRel is and what they do. There was this particular video that was very helpful. I also signed up for the DevRel-focused newsletter, DevRel Weekly. I went through some of their archives, and I read so many things about the DevRel industry. 

 In terms of technical preparation, I didn’t do so much. I already had so much frontend experience, and I was only looking for DevRel roles for frontend products. 

What was the interview process at your current company like? 

The first stage was the introductory meeting, which is the best part of most interviews. They got to know me, and I got to ask questions about the company and its role. I also asked what I’ll be doing, if I’ll have the opportunity to create videos or just articles, and if the company was working on any fancy project. Then, they asked me questions about my content creation process. 

Next, there were two technical stages. For the first technical stage, I was asked React-related questions. I was asked to present a React project of my choice, and if I didn’t have one, they would provide it for me. Thankfully, I had a React project that I had built. They went through the source code and asked me questions like: “why are you doing this?”, “Why did you not do this?”, “How did you handle authentication?” and so on. 

The second technical stage was where I was actually tested on DevRel skills. They asked me to develop a creative use case for their product and then build it and write a tutorial about how I built it. 

What use case did you come up with?

Stream mainly offers chat messaging APIs and SDKs, so I built an eCommerce application with a chat feature for a buyer and seller. Basically, when a buyer sees a product, they can initiate a conversation between them and the seller of the product. A conversation channel is created for the buyer and seller for that particular product, so they can negotiate. 

I built the project with Node.JS, React, and MongoDB for the database. Then I wrote a step-by-step tutorial on how I built it. After that, I wrote a detailed readme for the project’s repository on how to set the project on your own computer. I submitted it, and they loved it. 

How does your company measure the impact of DevRel?

We track page views and chat trials. We have a free and trial version of our product. When any new article is published, we track the page views, number of sessions, and the number of visitors that applied for a trial through that article. We also track the number of visitors who contact sales or fill out the contact form through those articles. 

Who or what determines the direction of the content your team creates? 

I don’t really have a direct say in that. I just come up with different ideas based on what I’m comfortable creating. I dump all these ideas on a shared doc. We have a content team they do their SEO research and find out which ideas are high in demand. They would also compare against an already written article that got a lot of traction. So, the decision lies with them. I just wait for their feedback on whether to push through with an idea or keep it in the backlog for later. 

What/who determines what you work on for each week and your deadlines?

So when I have approved ideas from the content team, I share that with my manager, and I ask which I should start with. Sometimes, I get to make that decision. Other times, he decides. Once we come to an agreement, I would create a card for that idea on our notion board, where we track content that is in the pipeline. I would also provide a deadline that I think is feasible for me. Of course, my manager would still review and point out if he thinks the deadline is too short or too long. 

What’s the content creation at your company and for yourself? How do you go from idea to finished content (articles or videos)?

In summary, ideas go into the idea dump, the content team and manager approve, then I create an outline. After creating an outline, I share it with the content team to get their feedback. If the outline is approved, I create the first draft. After the first draft, the article basically goes through a series of revisions till we are satisfied with the outcome. The process is the same for our videos. 

For my personal work, I also have a dump page where I dump ideas as they come to my head till I’m ready to pick them up. For each idea, I state what I want to explain and maybe websites that I want to reference for further info. When I finally want to write about an idea, I go-ahead to create a draft and grammar check it with Grammarly. I sometimes use Hemingway when I feel like Grammarly did not do enough work. After that, I create cover designs with Figma, then I publish them on my website. 

For videos, I start with writing a long script of things I should say and do at different points in the video. I may not have the strength to do the video on the same day. But, when I’m ready, I just follow the script and then edit. 

What are the tools/devices you use to create content (both articles and videos)?

Currently, to record my videos, I use my iPhone’s camera and a ring light. I have an iPhone 13 pro. I also have a shaw 7x microphone. I use GarageBand to record my audio. And to edit my videos, I use the paid version of Final Cut Pro. 

For articles, I use VS Code if I’m writing for myself because I write in Markdown. If I’m writing for the company, I use Google Docs, so others can comment and add annotations. Then there’s Grammarly for grammar check, Figma for cover designs, and Notion for idea dumps.

Based on your experience, do you have any best practices or do & don’ts towards content creation?

One of the most important principles I tell everyone is: if you want to get better at this thing, you have to do it consistently. 

Secondly, when I write anything, I try to read it from the reader’s perspective and try to identify sections that may be difficult to grasp, hence need simplification or an illustration or code block. I try to make sure that everything I write has as much context and is as straightforward as it can be. Another thing is to try not to create content for everybody. Focus on your audience. Some people will find your content helpful, and others won’t. 

For videos, my most important principle is remembering that the video is secondary while the audio is primary. Your video can be nice and everything, but if the audio is not clear, then I doubt many would get the message successfully. Secondly, focus on value and not on getting people to subscribe to your channel. 

So the way I do my videos, at the start, I immediately tell you what my channel is about and what I’m going to do in that particular video before I even get to ask people to subscribe. I would also mention consistency again and also experimenting. When I first started video, it was quite difficult for me. I used to record, pause, play, rinse and repeat. But now, I can go at a stretch and then cut out any part of the video that I don’t want. 

Last question; The target audience of this interview series are people who want to transition into DevRel roles, just like you did. Do you have any words or things you wish you knew while preparing to make the transition?

As you mentioned earlier, Dev advocacy is a nuanced role. Different companies have different requirements. I would say to anybody looking to transition, build some experience in any form of Dev advocacy, be it community, written content, video content, podcasts, or open-source. And, if possible, have a basic idea of other forms. That’s what will get you hired. 

For example, when I joined my company, I made it clear that writing was my domain and I wasn’t necessarily good at video creation but that it was something I was willing to get good at. Since joining, I’ve been able to create two videos for my company. You don’t really have to meet all the checkmarks of a DevRel before you can be employed. With solid experience in one domain, you’re good to go.

And that’s all from Dillion. If you want to learn more about Dillion, check out his YouTube channel or website, or reach out to him on Twitter.  Till I come your way next month with a new guest for #DevsinTransit , stay jiggy!.

Categories
Tips

How to Upskill Your Cloud, SRE, and DevOps Experts to Empower Your Organisation

How to Upskill Your Cloud

Developer Nation is continuously trying to bring high quality articles for your career path and your company/organisation among insights, tips, interviews and more from the developer ecosystem. This time we have the honour to host an article by IOD about roles, career growth and leadership, focusing on Cloud, SRE, and DevOps Experts.

This article was contributed by IOD.
IOD is seeking new tech bloggers. If you are a top notch tech expert or a writer, join IOD’s talent network and share your expertise!

Today, every company is leveraging technology to innovate, streamline operations, and create value for their customers. Regarding software engineering, developers have a natural and prominent role in creating new capabilities and opportunities, but that cannot happen without a greater support infrastructure. Cloud, SRE (site reliability engineering), and DevOps engineers are central to value delivery and business continuity. It is vital for engineering managers to understand how they can become mentors in order to coach and upskill these experts to both enable their career growth and increase business value.

Distinctions Between Expert Roles

Modern software development teams work in a DevOps way, by bringing people with different competencies together and enabling a faster, higher-quality value delivery and development lifecycle. 

Writing the application business logic is only part of the engineering equation needed to deliver customer value. The other part, operations, includes many tasks that are mostly driven by Cloud, SRE, and DevOps experts. Good examples of those tasks are designing scalable and reliable systems, ensuring that code can be tested and deployed using continuous integration and delivery pipelines, monitoring system health, and implementing security and compliance guidelines.

Personally, I dislike the title “DevOps Engineer,” because DevOps is applicable to the entire engineering team and is a more abstract concept. SRE, on the other hand, is a concrete implementation of the DevOps philosophy—experts in an SRE role bridge the gap between developers and operations. A DevOps engineer (what I prefer to call the “automation/cloud specialist”) differs from an SRE, as they only focus on systems operations.

There are some natural derivations in lateral roles that come from further specialisation in certain technology areas such as DevSecOps engineer, chaos engineer, or cloud and solution architects at more senior levels. 

SRE and cloud specialists are crucial to the success of the product or service. Yet, they are too often disconnected from the business reality; this is where coaching and mentoring makes all the difference. 

Mentoring Is Vital to Career Growth

Engineering managers have the lead role in mentoring and coaching these experts: guiding, providing feedback, showing different career possibilities, and building bridges within the rest of the organisation. Engineering managers can act as human routers to make the connection between experts and business stakeholders, ensuring experts get first-hand knowledge and visibility on the value and end-user experience of the product(s) and service(s) that they work on. 

Similarly, managers can then demonstrate to stakeholders the positive business impact of these experts’ actions. Does the solution have a great reliability track record and always meet the agreed SLAs? Tell them about it! What would it take to enable solution architecture to scale ten-fold and be available in other geographical locations to support new business cases? Great conversation starter! 

How to Make It Happen

Unfortunately, business stakeholders usually only connect with these experts when something goes wrong (e.g., a system failure), and need to understand what happened and why. Engineering managers can change this pattern and create a new paradigm.

Here are a few things managers can do to establish this paradigm and foster its culture:

  • Translate business and industry-specific jargon into technical concepts, examples, and terminology that experts can relate to. 
  • Help experts develop the necessary non-technical skills to communicate effectively, and translate complex engineering scenarios into simple, relatable terms and ideas with business impact.
  • Facilitate sessions where experts can present and showcase potential opportunities that new cloud and data technologies can unlock in the organisation, generating new business models or streamlining existing operations and processes.
  • Create and explore opportunities for experts to shadow and connect directly with colleagues in different roles across the organisation, such as working alongside a customer support representative or joining a sales meeting.

This enables constructive cooperation across competencies, breaking silos while helping these experts grow and gain a better understanding of their impact in the organisation.

Upskilling, Community, and Thought Leadership

There is no substitute for hands-on learning, and engineering managers have a unique role in creating those opportunities. It’s important to maintain a continuous dialog to understand the expert’s career goals and interests, while simultaneously facilitating situations that enable them to gain new hands-on experience.

Simple and small steps, such as inviting them to a steering meeting, participating in a technical brainstorming workshop, or joining a new, exciting project (even if in a minor role) can make a huge difference and impact. Venturing out of one’s comfort zone is always an opportunity to grow and learn.

Further, hands-on experience should always be accompanied by other learning and input, such as insights from other experts, industry certifications, or non-technical skills development.

Certifications and Digital Content

Consuming digital content—articles, videos, whitepapers—and pursuing industry certifications—such as those offered by AWS, Microsoft, Google, and the Cloud Native Computing Foundation—are both excellent practices for validating existing knowledge and discovering new services, expert insights, and best practices.

Each of these organisations offer certifications that go from the fundamentals to complex solution architecture scenarios, focusing on areas such as security, networking, and data engineering. When combined with hands-on experience outside of typical work tasks, content-learning and certifications provide natural upskilling and specialisation pathways that stay with the expert even when changing jobs or companies. 

There are also plenty of advantages to an organisation that has certified experts. It nudges the organisation toward good practices and ways of working, while enabling the company to level up their cloud partnership status and showcase their expertise to customers.

Technology Communities

In organisations, from SMBs to larger corporations, there is a natural tendency for individuals to become siloed in their team and/or business unit. Cloud, SRE, and DevOps are domains transversal to all development teams and organisational structures. Fostering an internal technology community where these experts can regularly meet increases alignment and promotes a healthy exchange of ideas. Moreover, it enables these experts to drive the technology governance and foster a culture of engineering excellence across the organisation.

Similarly, external communities and events are also a great way to gain new insights and fresh perspectives. DevOpsDays, ServerlessDays, as well as AWS and Azure Community Days and Meetups, to name a few, are fantastic options to learn and meet like-minded people. With practically all events now fully virtual and often free to attend, this is something that should be highly encouraged and promoted in your organisation.

Sharing Experiences and Thought Leadership

Engineers, especially less experienced ones, might be intimidated at the prospect of sharing their insight and experiences in technical articles or public speaking engagements. Regardless of the level of the content, whether beginner’s guides or more advanced deep dives, there is considerable value in creating content and sharing knowledge. Entry-level content from a Cloud, SRE, or DevOps expert can offer tremendous value to a developer or business stakeholder not familiar with the topic, and it can help bridge gaps between different competencies.

From a career growth perspective, an expert that invests time and effort in thought leadership activities—including written content and speaking engagements—is more likely to accelerate their professional growth and seniority. This is not first because of the positive visibility that those activities bring to themselves and their organisation (that helps!), but rather, it enables the expert to radically improve and develop valuable communication skills. Simply, with practice comes change; the more we work to translate and express complex thoughts and ideas into written and verbal content, the less subject we are to our own silos. 

Conclusion

Coaching and upskilling Cloud, SRE, and DevOps experts reveals new possibilities for impacting how an organisation operates and delivers. With these experts, it’s critical that direct managers and senior leadership start seeing and treating them as essential value creators, not cost centres.

When mentoring these experts, help them understand their potential career paths and growth, and highlight the value they create and the impact they make in the organisation. Most importantly, be transparent, provide constructive feedback, and foster a psychologically safe environment that encourages them to venture beyond their comfort zone and try bringing in new ideas.

Categories
Community

Cheat Sheet – Developers, unite! Have your voice heard.

This is a cheat sheet focusing on the Developer Nation 23rd survey wave, giving you all the key details to make the most out of your experience:

What
11+ years of surveying developers.
The Developer Nation survey has been measuring the preferences, needs and wants of developers for more than 11 years. It’s a dynamic survey where each participating survey taker will have a unique path, based on their own background and experience. 

When
The Developer Nation Community will be launching its 23rd survey wave on June 2 in English. On June 9, the survey will be available in all other languages: Spanish, Portuguese, Chinese Traditional + Simplified, Korean, Russian and Japanese.

Who is it for
Developer Nation is borderless! Everyone’s welcome! 
The Developer Nation survey is global and open to all. In the previous edition, more than 20,000 developers and creators of all levels – from students to hobbyists and seasoned professionals – from 160+ countries, shared their views. 

We want to hear your opinion if you see yourself as a developer, software engineer or tech creator involved in Web, Mobile, Desktop, Cloud, DevOps, Industrial IoT & Consumer Electronics, AR/VR, Apps/extensions for 3rd party ecosystems, Games, Machine Learning & AI, and Data Science.

If you nodded at any of the above areas or descriptions, this survey is for you. Keep reading for the benefits of participating or start now.

Why participate
There are several benefits for those who take the survey. Some of these are:

Prizes
By participating, developers can win amazing prizes and unlock more as they proceed, including a complimentary virtual goody bag packed with free resources. 

Premium access to information
Understanding the trends can be paramount to developers’ next career move. We share the results, data and ecosystem insights with the participants and tech organisations who use the data to improve their developer offerings. 

Giving back and helping others
For each qualified survey response, we will donate USD $0.10 to a charity of your choice. Our goal is to reach USD $1,800+ in donations. Take the survey, pick a charity to support, and help us make a difference.

What’s different this time
Every wave is a new opportunity to give developers what they want. Here’s the latest benefits we introduce in this 23rd wave:

  • Weekly prize draws, including everyone who signs up to take the survey.
  • Special Prizes to be drawn for everyone taking the survey in the first 48 hours (2 winners: Nintendo Switch & iPhone 13).
  • A new way to reward participants: the more questions you answer the more chances you get to win. A participant’s name will be included multiple times in draws depending on the number of questions answered. 
  • Prizes include: Nintendo Switch, iPhone 13, Xiaomi RedMi 11, Samsung Galaxy S22, Amazon Echo Dot 4th Gen, Premium Subscriptions and Licences, Vouchers for online courses and tutorials, Gift cards and vouchers for Amazon, Spotify, Apple Store, Google Play, cash to fund your development projects or towards the gear you need up to $1,000 USD and many more prizes drawn every week.
  • Everyone who completes the survey will receive a virtual goody bag filled with free subscriptions, discounts and vouchers. 

You read this far, which should mean you’re interested. Why not start the survey and share your views on key topics only developers can understand? If you’re short of time, you can save your progress and continue later (you’ll need to sign up to save). 

Are you creating for AR/VR?
There is an additional, exclusive, survey dedicated to Augmented, Virtual and Mixed Reality creators, with the same benefits. AR/VR creators can share their reality views using this link.

Categories
Tips

When the problem is: incomplete bug ?reports

Bug reporting

Fall in love with the problem.

We love sharing stories of small teams or even groups of friends getting together and developing innovative products. What’s more interesting is the journey they take as well as the difficulties they face and the learnings they acquire.  Today we shed light on the story of a small product team who left their jobs to work on an idea that at first seemed simple but turned out to be quite an adventure! Here is the story of Adopto Bug Fixing – an automated bug reporting tool that helps tech teams receive fast and detailed bug reports.

Our adventure as a startup starts with a product team composed of a product manager, a tech lead, a full-stack developer, a UI designer, a QA tester, and a user researcher. We’ve always shared the desire to build something new to be proud of, so one day we decided to leave the previous company for which we were all working and follow the dream of building our own product-based startup.

“Fall in love with the problem” is the most popular recommendation shared among product people, and those founding a new startup. But here we’re talking about a startup whose 80% is made of builders, people who love to do one specific thing: build solutions. As Dan Olsen once said, “We live in the solution space”, and this is probably the truth when talking about a tech team. So we initially tried to use a shortcut: validating a solution without having validated the problem, as many did before us. We began this adventure with a solution in mind, a leftover from our previous experience, and we tried to look for a fitting problem, and for a market segment that could be interesting. A bit like when you are a child playing with geometric wooden shapes and you try to fit a circle where you should put a square. A true nightmare. 

Like many of you surely know, what you should be doing before developing a product, and even more during the very first months of a product-based startup, is NOT building and developing solutions. Your time and energy should be focused on a series of problem discovery activities, ranging from customer interviews, and market research, to competitor analyses. Luckily for us, after banging our heads against a few brick walls, we realized that the solution we were developing wasn’t going far because there was no problem-solution fit, so we hit the brakes and pivoted away.

We braced ourselves with patience and started our quest for a problem that was worth solving and could make us passionate about. “Since we are a product team”, we said, “let’s start exploring some product-team-specific processes”. We deep-dived into processes related to developing new features and those related to the resolution of bugs and technical incidents. Of course, fixing bugs appealed to us much more than developing new sexy features! 

We’ve spent the last four months doing customer discovery, interviewing potential customers, talking to them on LinkedIn and Reddit, on Discord channels, and in many product communities active on Slack (p.s. If you ever need feedback on any product you’re working on, I’d suggest getting in Mind The Product, The Product Folks, and The Product Coalition. Everybody is super generous with their feedback and ready to help out). As you can imagine, we had to work against the natural tendency to find shelter in the solution space, especially when at first we couldn’t get many people to talk to. But we managed, mostly because we were scared otherwise we would have to pivot again, and that’s a very painful process, as some of you can surely confirm. So after having chatted with hundreds of people among product managers, customer support reps, and account managers working for companies of various sizes, colors, and shapes, we validated that indeed there is a real problem with bug reporting.

Apart from some specific peculiarities that define every company, the current process that is followed in many places can be simplified like this: bugs (or presumed ones) found by end-users are reported to customer care or customer support, who are then responsible for the thankless task of manually collecting some technical information that is often hard to get -just imagine you need to ask an average user to share the screen and use the browser inspector to be able to check console logs. Then the customer support agent gets to open an issue to report that information in a ticketing system, following a more or less structured process.

This process creates a clear bottleneck: the team responsible for the resolution of the bug receives a report that is usually not very detailed. Not only doesn’t that help identify the steps to reproduce the error, but incomplete reports often lack the technical specs needed to distinguish between a real bug and a device/user-specific error, or even a bad design. This is why, once the ticket is opened, bug reporters and developers initiate a conversation that goes back and forth several times to request the missing details. Sometimes, customer support agents are even forced to reach out again to the end-user to find out more about the bug. This bottleneck is strongly felt by both parties involved: it is an eternal ping-pong that leads to a waste of time, without having any assurance that the bug will eventually be identified and fixed.   Here we’ve collected some of the most interesting learnings we gathered on the way. We’d love to share them with you: 

1. There is no need for a process…until you actually need one!

The very first thing we learned during our customer interviews is that there is a specific moment when you realize that your team won’t survive if you don’t put in place a somehow structured bug reporting process.  We noticed that teams usually move from receiving direct calls or Slack messages from colleagues finding bugs to having a dedicated space to collect all reports. You can have a basic version of this, like a shared spreadsheet, or an #issues Slack channel where the tech team manages to gather all complaints shared by colleagues. Those in need and the bravest, too, even go a step further and build a template to guide colleagues in what details they need to reproduce and triage the bug, so they can quickly define its priority in the backlog.  

What are the details that if present speed up the whole bug reporting process?

  • Where is the bug? – That is, all information that allows the team to exclude problems that are not widespread, but related to certain devices, OSs, browsers, app versions, or even user IDs.
  • Steps to reproduce – The actions that led the user to find the issue. The golden rule is “the more detailed, the better”. Usually, this information can be obtained only by directly asking the end-user to describe the process they follow that brought them to the bug. 
  • Expected behavior – Bugs are very often unfortunate design choices that produce some friction when using the product. To be able to spot these non-bugs, it’s important to ask the user to clarify what behavior they were otherwise expecting to see.
  • Technical details – In an ideal world, frontloading helps make the bug resolution process overall more efficient. This is why it is a good practice to immediately collect all those technical details which could later help testers and developers identify the issue, such as network requests, and console logs. When reproducing the bug is not straightforward, details like these come really in handy. Yet, collecting them is a real pain for non-technical colleagues who have to directly ask customers and users. Imagine asking a user to share their screen and activate the Browser inspector so that you can collect the logs. A bit of an extreme situation, especially when dealing with users with low digital literacy.  
  • Priority – The goal is to provide the tech team with an estimation of how quickly they should act on the bug and plan accordingly for the next sprint. This metric can be determined by different factors, such as the number of users that could experience the bug, or the importance of the feature that results affected, but also the impact of the reporting client on the company’s total revenue.  

Unfortunately, the truth is that all the effort put into providing colleagues with a template that guides them to report a bug doesn’t always pay off. There will always be someone who won’t follow the suggestions, who prefers to spontaneously make a phone call or send a Slack message directly to the product manager or a developer. And from here we move to the second learning.

2. Templates are useful, but never enough

At least once in our professional life, we’ve all witnessed a colleague who refused to adjust and use a new tool that would have facilitated and sped up not only their work but everybody else’s. This is because the adoption curve for an internal tool of this kind follows the sinusoidal shape of any other technological innovation introduced in the last two centuries (but have a look here to read how the pace is gradually speeding up).

What’s important to bear in mind is that for any new tool or process, there will be one or two colleagues out of ten who will enthusiastically try it out – the so-called innovators and early adopters. Of the remaining eight, though, seven will need to be convinced, pushed, and engaged even just to give it a try, and one-two will likely never accept change. This is the truth, it hurts, but the sooner we accept it, the better. 

Source: https://www.cblohm.com/blog/education-marketing-trends/adoption-curve-education-marketing-strategy/

3. Priority is not mathematics

Chatting with many product managers we identified another point that is very, very painful: even when you have some guidelines about how to estimate a bug priority, non-tech colleagues always report “High priority”.

“Consider, high priority is given even when they are talking about a typo or a misaligned button in the interface of an internal-use-only platform”, many confess with frustration.

This is truly one of those cases where you get nowhere: every team has its own KPIs and success metrics. If we ask a customer support rep, they will say their goal is closing support tickets as fast as possible. If we interrogate an account manager, it is high retention rates and an NPS equal to or higher than 9. And indeed, helping the unsatisfied user or client by making sure the problem is fastly and efficiently handled seems a very high priority for these roles, which are usually the most active in reporting bugs and technical issues in the first place.

Work chronicles

The only thing we can do is take this factor into consideration, and use some empathy –  yep, exactly the same empathy we try to use with our users! These colleagues have different goals and jobs to be done, so get ready with a bug triage process that is independent of the level of priority that they will mark. From here we move to the next learning: the (oftentimes unsatisfying) conversations between the tech team and non-tech colleagues.

4. “Yep, sure! I’ll let you know” doesn’t work

We’ve just mentioned that the product/tech team’s KPIs are quite different compared to those of colleagues working in sales and customer support. Let’s play a role game and get in our colleagues’ shoes -we have to apply that empathy we mentioned above: I’m a customer support agent and a client contacts me to report a technical issue, I bring this information to the tech team after collecting as many details as I can (although I’m sure the developer won’t be satisfied, as usual). It should go without saying that my need is to be able to check the status of my report so that I can show the client that I’ve not forgotten about them, I’ve paid attention and made sure their problems will be solved asap. Even when they contact me again the following days. It’s easy now to empathize with this colleague, isn’t it?

Then you should be surprised to hear that many of the customer care reps or account managers we talked to are not satisfied. The “Yep, sure! I’ll let you know” they receive from their tech colleagues doesn’t satisfy their simple needs. Most importantly, it doesn’t give them the chance to do their job at their best. Of course, we cannot expect the same colleague to then go the extra mile to gather all the details to make our job easier and less frustrating, am I not right?  

Companies that believe in a powerful alignment between product and sales/customer care invest a bit and provide non-tech colleagues access to the product’s task management platform (e.g., Jira, Trello, or ClickUp just to name the most mentioned). In this way, as a task progresses, the colleague receives a notification and can address the angry client who’ll get in touch again the following day.

5. QA testing is not sufficient 

The very last learning we want to share is about testing, and here we really collected mixed feelings. On paper, all product teams acknowledge how important it is to have a testing procedure in the pipeline before releasing changes to production. This procedure should guarantee that code is error-free, what’s known as Quality Assurance (QA) testing, but also that the user experience and the app usability are optimized, known as User Acceptance Testing (UAT). Everybody agrees this should happen.

Yet, about half of the people we interviewed confessed they don’t have dedicated resources for testing activities. In some cases it’s the product manager that carries out the task, testing the product and trying to imitate dummy user’s behaviors, such as clicking on the wrong buttons. In other cases, it’s the developers who test what they just built – and here we could (but won’t) start the huge debate on the validity of this practice (refer to this article to check popular arguments on the topic).

Nevertheless, there are several organizations where not only is QA testing done properly, but it is also automated to be very efficient and limit human errors. Nowadays many tools automatically notify you when they find code-specific errors, nothing new on this site. Yet, as many confirmed, the problem is that many bugs are not really bugs (strictly speaking, only code-specific errors are). Most of the time, the “bugs” are actually unfortunate UI/UX choices that the user perceives as technical issues. These cases represent the majority of the reports that tech teams receive, according to the product managers we interviewed, and there isn’t much we can do except bracing ourselves with patience and a desire to improve.

Adopto Bug Fix

You are probably wondering how our startup’s story ends now that we’ve finally learned to carry out a proper customer and problem discovery. After all the interviews, the individuation of the problem, of the job-to-be-done with the various pain points associated with it, we finally moved to the solution space. And here we started defining and building Adopto Bug Fix: an automated bug reporting tool that helps tech teams receive fast and detailed bug reports, without wasting time and precious resources in back-and-forth conversations with customer care and end-users.

Picture this: a user gets in touch with customer support to report a technical issue, the rep simply asks the user to press a keyboard shortcut, or click on a button on the app, and to reproduce the same steps that led to the error in the first place (this last one is a standard procedure that customer support usually carries out when receiving a report). That’s all!

Adopto Bug Fix works with a snippet of code that is pasted into the target platform’s code. It behaves like Siri: it’s quiet and invisible to the users’ eyes unless it’s activated. After the activation (with a keyboard shortcut or a click on a button), Adopto starts recording the session and collects a series of information. Among the information that it collects: there is a screen recording to check the user’s behavior on the app, the user clicks and text input, console logs, and network requests. But also specs about device and OS, screen resolution, and user ID. All these structured details are then conveyed in a report that the team can access from our platform. The report can be easily shared in any task management system. In this way, you can exploit the existing communication process you already follow to share updates with non-tech colleagues (we mentioned this at point 4).

As for today, we are in the Beta phase, meaning that we are improving the user experience and developing new functionalities thanks to the help of some product teams that have started using Adopto in their bug reporting workflows.
These teams are young (not talking about age, but about product maturity), have a WepApp currently under development, receive many incomplete bug reports from end-users and colleagues, and have tried to solve the problem with a solution that didn’t bring the expected results. If you see yourselves in this description and believe Adopto could make your team’s life easier, check out our webpage and sign up to become a member of our Beta program!

Sign up for free for our Beta program