Why Developers Should Engage in Continuous Learning

This is a guest post from Jerrin Samuel. Enjoy.

Dear new developer,

Software development is a field that evolves quickly and constantly. These changes keep things exciting and interesting, but can also make you feel like you are falling behind all the time.

Engaging in continuous learning is one of the solutions you can look into to stay updated in your profession and avoid feeling left out.

Continuous learning refers to the process of learning new knowledge and skills on an ongoing basis.

This type of learning can come in various forms, including enrolling in formal programs, such as taking up technical training courses, attending seminars, and engaging in self-study. It can also be sponsored by the employer or take place within the company, or it can be personal.

Benefits of Actively Participating in Continuous Learning

Continuous learning provides professionals in the field of software development several benefits, which include:

Remaining relevant

Since software development is a constantly evolving field, you need to stay up-to-date with all the changes that come up.

Taking up development or IT courses allows you to keep up with the latest trends. Moreover, you can broaden your knowledge and skills, enabling you to adjust and function effectively in the dynamic world field of technology.

If you want to remain valuable in your organization, you have to learn new things constantly.

Boosting your profile

Learning constantly means you are continuously growing and improving.

This also means adding more skills to your CV and profiles on various recruitment and job posting sites. These additional highlights can make your profile stand out and catch the eye of more recruiters and employers.

The certificates you gain and the recommendations by your managers and colleagues will also make your profile more attractive.

Improving your employability

Professionals who are constantly learning and upgrading their skills create a higher market value for themselves.

This is because employees that always stay relevant are highly sought after in the job market. As a result, employers go another mile to hire or retain them.

Preparing for the unexpected

Continuous learning helps you acquire skills that can propel you towards achieving success not only in your current workplace, but also in other companies.

Since the economy can be erratic at times, you need to be prepared for the possibility that you may lose your job. Having broader, up-to-date skills can increase your chances of getting employed again as soon as possible.

Your broader range of skills can also give you the confidence you need to take on new job opportunities so that you can get employed faster.

Increasing your self-esteem

Learning new things gives you a feeling of accomplishment. This, in turn, enhances your confidence and belief in your capabilities.

As a result, you will also feel more ready and confident to take on challenges and new job roles and responsibilities.

This boost in confidence will also improve their emotional and mental health. What’s more, it will increase their productivity.

Enhancing your creativity and problem-solving capabilities

Joining software development courses, seminars, conferences, and other reskilling and upskilling programs allows you to learn from the trainer or facilitator and your fellow learners.

Because of this, you will be able to come across new perspectives, techniques, and strategies that can help you think outside the box.

Whether you come across a problem that requires innovative solutions or need to create something new that has never been done before, you can also use the knowledge you learned from others to meet these challenges.

Broadening your mind

Continuous learning allows you to expand your mind and perceptions, thereby helping you change your attitude.

The more you learn, the better you will be at seeing things from different perspectives.

Your open-mindedness can help you relate and communicate with people more effectively. Whether you want to broaden your professional network or social circle, your new outlook and attitude can set you on the right track.

Getting the Most Out of Continuous Learning

When engaging in continuous learning, consider trying out different strategies. Aside from taking formal in-classroom and online courses, seminars, and workshops, be open to joining employee and managerial training programs.

Participating in social learning opportunities, such as team meetings or discussions and collaborations, are also effective strategies for upskilling and reskilling.

Coaching, mentoring, and on-the-job training programs also count as social learning opportunities, and thus, will contribute to your personal and career growth.

Lastly, there is also nothing wrong with branching out if you are interested in other fields. If you have the opportunity, learn skills not related to software development but can still contribute to your personal and career growth.

A project management, business writing, or employee motivation training course are excellent options to add to your portfolio.

Learning should be a continuous process. Always include it in your goals to experience growth personally and in your career.

Sincerely,

Jerrin

Jerrin Samuel is the Executive Director at Regional Educational Institute (REI) in Abu Dhabi. Since 1995, REI has been at the forefront of education by delivering quality corporate training courses in the UAE, helping many businesses and organizations achieve greater productivity and higher customer satisfaction levels.

Take jobs that help you grow

This is a guest post from Adam Steel. Enjoy.

Dear New Developer,

Getting your first developer job can feel like a big accomplishment. And it is! It can feel so big and you can feel so relieved to have any job at all that you might start to develop your worldview around that one job. “This is how things are in the real world” you might tell yourself. “I’m lucky to be here,” you murmur. “Leaving too soon looks bad on your resume,” says an older friend.

This sort of thinking can be entrapping. I’m writing to show you a better way.

The spectrum of jobs and companies in tech is broad. To understand how the world is and what your options are you have to take a couple samples and grow, grow, grow! To that end, there are three “traps” I see developers get stuck in early in their career.

The first trap: Spending too long at your first job

In your first 3-4 years, it’s critical that you fuel your motivation and inspiration into learning and growing. It’s also a critical time for a steep increase in your salary. Too many companies fail to recognize that a junior developer’s abilities are growing far faster than their compensation and responsibilities. Or it’s recognized but the company cannot afford to promote or give a raise. It’s up to you to take the reins and move to a new job to find the new challenges and new salary that match where you are in your career. This is especially true for self taught and boot camp taught developers.

How long is too long? How long is enough?

“Enough” time as a junior can be surprisingly short, depending on how you learn. At 6 months it is reasonable to consider switching jobs if you are learning quickly. Not for all positions you’ll hold, but specifically for this first one. Juniors are paid less because they need to come up to speed on all the terminology, tooling and processes.

Once you don’t need hand holding to tackle moderately complex features, you will be far more attractive to other companies. Occasionally a company may recognize and reward your growth, but that is rare.

Stay longer only if you’re feeling significantly rewarded and challenged. Which brings me to…

The second trap: Not investing in learning

Building business software in teams requires a set of skills that are hard to acquire in the absence of customers and a team working to support them. This learning curve can only be tackled when you have these components. And the best way to move along the learning curve is to take a job that helps you learn faster!

What does a “learning” job look like?

“Learning” jobs tend to have similar characteristics. There are resources to learn from and the autonomy to work however suits you best. There is time built into the team’s cadence to allow for research, either organic time throughout your week or time specifically set aside.

Most importantly, there are lots of smart people who give you feedback and engage in discussions about the best way to do things. These people will focus on things like best practices, optimization and customer value. Often they argue! While the arguments might excite you or wear you down, they should feel overall productive and, at the end of the day, move the team toward its goals.

Think of a learning job like an additional career investment, beyond whatever you’ve already paid to learn before your first job. What you need is exposure to good ideas in the context of solving a business problem with an experienced team, and a good learning job gives you that. You may take a lower salary in the short term, but by expanding your knowledge your career will be more fulfilling long term.

What should I avoid?

The list of positions where learning is difficult is much longer than the list of “learning jobs”, but here are some examples:

  • Isolation: Working alone is the hardest career decision to come back from, but it’s especially destructive in your first job. If you aren’t challenged by the ideas of multiple people, your world becomes small. You also won’t have a chance to build your network.
  • Micromanagement: Good companies work to give their developers autonomy and space to do the right thing. If someone is managing the details of your daily life, you aren’t learning how to flex that autonomy muscle. For example, once I had a job where a senior manager stood over my shoulder and dictated what he wanted to see as I wrote code.
  • Lack of visibility: Do you get a chance to learn how the pieces fit together? Do you get a chance to fit them together? A narrow field of view restricts your ability to build a larger context. For example, are you only ever asked to fix specific bugs, or are you encouraged to think about the larger architecture while building new features?
  • Unsafe environment: If we don’t feel safe, we cannot learn well. Depending on the threat, there could also be much bigger concerns. Examples include, but are not limited to, yelling or harassment of any kind. Leave as quickly as you safely can.

The third trap: “Being glue”

“Being glue” is when your role is focused on filling gaps like coordinating between teams and keeping everyone organized, as opposed to actually writing software. Especially in smaller, more dysfunctional teams it can be a tempting role to fill. The team needs it, after all! It’s an important role for managers and higher level engineers to fill, but if you step into it too early it will stunt your learning curve and can leave you forever feeling like you are “behind” the rest of the team. It’s first (and best) described in this noidea blog post.

Once you are technically competent, and everyone knows it, consider taking on this work.

Finding a job that maximizes your growth

There’s no silver bullet for this problem. My best advice is to try to develop the ability to “sniff out” the kinds of companies you’re looking for. Did someone impressive speak at a meetup or write an inspiring blog post? Track down where they work. Job descriptions that are well written and articulate good values are promising. And if you end up in a job that you misjudged and find yourself stagnating, don’t feel guilty about quickly moving on.

Consultancies with great practices, like TestDouble, can be great accelerators for your learning. Changing projects more frequently results in a broader experience, but at the predictable cost of less experience with how your decisions in a codebase will age.

What does a “good” job description look like?

Writing a good job description is hard, but the best companies will put in the effort to do it right. Some attributes of good job descriptions include:

  • Reasonably correct English and readable formatting
  • A description of philosophies and values that align with yours
  • Reasonable requirements (e.g. no CS degree required for a junior level frontend position)
  • Specifically calls out personal traits like kindness or empathy as desirable

What can I ask in interviews to vet the position?

Remember that interviews are your chance to interview them as well. Examples of questions you could ask include:

  • What best practices do you think have made your team successful?
  • What kind of developers thrive at your company?
  • How do you support developers when they come onto a team?

How frequently can I change jobs?

This is a hot topic, but varies by which part of the industry you’re in. Early on, hopping jobs more quickly is fine. 3 jobs in your first 3 years? Not uncommon. Working in startups especially can lead to shorter tenure as companies fail or are acquired.

However, there are skills and wisdom you will only be able to build by staying longer. For example, no amount of training or reading will result in the wisdom you gain by wrestling with a technology decision you made over a year ago as you watch it cause painful issues.

The resume to avoid building is the one with only <2 year tenures over a 10 or 20 year career.

Happy growing!

Adam

Adam Steel is the VP of Engineering at TrueCoach. He lives outside Boulder, CO.

You’ll always be learning

Dear new developer,

One thing I love about software development is that you’ll always be learning. This is because of two things.

First, there’s better and different hardware. It is possible that this pace will subside sometime, but looking at the variety of new computing hardware, sensors and components that have been created over the last 60 or so years gives me confidence that we’re at the beginning of computing becoming a utility, just like electricity. This is one of my favorite essays on the topic. This new hardware gives rise to new capabilities. Just like GPS in the phone gave rise to Lyft and Uber, I think that small connected sensors everywhere will give rise to new companies and software development opportunities.

The other reason why you’ll always be learning is that software itself is evolving. This is a very young profession. I believe at some point it’ll be as established and systematic as, say, civil engineering, but I think that’ll be decades if not longer in the future. That means that practices and tools are continuing to evolve. They both take advantage of new hardware, of practices learnt from other disciplines, and of lessons as systems are built. I already gave you an example of the first, but an example of practices lifted from other areas of knowledge is chaos/resilience engineering. An example of the last lesson is containerization and immutable infrastructure.

If you choose to be a developer, your career will be filled with learning. Enjoy.

Sincerely,

Dan

Learn curl

Dear new developer,

If you interact with web APIs at your job, learning curl is a good investment. Curl is a flexible, powerful, command line utility which lets you make HTTP requests.

In my current job, I build a lot of API requests. Side note: I’m going to use the shorthand API for web based, JSON API; there are many other kinds of APIs, but curl is mostly useful for this type of API.

I’ve found familiarity with curl to be very helpful as I create, share and debug these API calls.

Why learn curl?

With curl, I can easily script up API interaction. In the next section, I’ll discuss the common parameters I use.

Curl works across multiple platforms. It’s a lowest common denominator tool and is present everywhere. It doesn’t require anyone to install anything. (Okay, maybe not true on vanilla windows, but as soon as you have any unix based system, you have curl.) Update 7/21: curl is present on vanilla windows 10. Open up a cmd window and run curl and you’ll see curl: try 'curl --help' for more information.

You can share scripts with team members, add them to issue comments for provide bug reproduction steps, and version control them if you want to improve them over time. I find them especially helpful for issue reports, as there’s no ambiguity with a script.

Curl pairs nicely with jq (which you should also learn); you can pipe the output of curl directly into jq to get understandable formatted JSON.

I find when I use a low level tool like curl, I’m forced to have a deeper understanding of the problem than I would if I used a higher level tool. It’s kind of like a text editor in that way.

I haven’t run into a situation yet where curl couldn’t interact with an API in a way I wanted, though sometimes multi step interactions like an OAuth authorization code grant can be a bit cumbersome. You can set headers, provide cookies, send a request using any HTTP method, and provide data either inline or via a file.

Basics of curl for APIs

Here are the main switches I use with curl for API interaction.

-X <method> lets me specify the HTTP method, so -X GET is a get request and -X POST is a post request. Sometimes the HTTP method is implied by other switches, but I prefer to be explicit.

-H <header> lets me specify HTTP headers. You can use this many times in one command. Often if I’m sending JSON in a post with an authorization header, it’ll look something like -H 'Content-type: application/json' -H 'Authorization: Bearer APIKEYHERE'

-d payload lets me specify a payload for a post or put request. This will often be JSON: -d '{"foo":"bar"}' It can be multi-line if needed. I use single quotes around the JSON to avoid having to escape double quotes. If I need to have a shell variable inline, so that I can extract some text which changes often, I do something like this: -d '{"foo":"'$BAR'"}'

-d @payload lets me put the payload in a file and have curl read from that file. I use this switch less often, because I’ll usually put everything in a shell script anyway.

-vvv lets me see the back and forth of the HTTP requests and response, and also status codes.

As previously mentioned, I also usually wrap everything in a shell script so it is repeatable. On occasion, I’ll even check the shell script in, so that others can use it. This is useful if it is a part of a run book or troubleshooting guide, for example.

Here’s a typical curl shell script, in all its glory:

API_KEY=...
USER_ID=...
curl -vvv -H "Authorization: $API_KEY" -H "Content-type: application/json" -XPOST 'https://api.example.com/user/'$USER_ID -d '{
  "user" : {
    "name": "Dan",
    "blogger": true,
    ...
  }
}'

There’s a lot more available with curl; the whole man page is worth a read. But I hope I’ve convinced you that you can use curl to interact with APIs in a way that is:

  • repeatable
  • shareable
  • versionable

Alternatives

There are many alternatives. I am a bit familiar with postman, which is a web based application that lets you organize and call APIs. There is also a command line runner for postman called newman. Insomnia is another option that some of my team members use. It’s another GUI client with a corresponding CLI client called inso.

While I haven’t dug deeply into these alternatives, at first glance it seems to me that they give you tooling power and richer collaboration. But nothings free; you lose ubiquity and simplicity.

curl is a powerful tool, available everywhere, for examining and interacting with APIs. Learn it well.

Sincerely,

Dan

Make it open source

This is a guest post from Eddie Jaoude. Enjoy.

Dear New Developer,

I will be the first one to tell you that it is not essential to have a degree in computer science to become a developer. My own journey started with a degree in engineering and falling into code as a mix of a hobby and also by necessity in my first graduate job. I have seen so many others in the tech community follow different paths to becoming developers; such as primary school teachers and historians.

Whether you have always wanted to become a developer or whether this is a new start for you, the likelihood is that you will be looking for learning resources from blog posts, YouTube videos and online courses. There are so many resources available, many of which are free, which means that you can improve your abilities without having to leave your house – which in a Covid era is quite handy.

However I would say to you – do not fall into the trap of getting stuck in “tutorial hell”. Thirst for knowledge is a great thing – and a good developer will realise that at no point in their career will they know everything and you do need to keep learning.

This is a little like going to the gym: you’ve decided you want a six pack – your trainer has shown you where the three different ab machines are and how to use them, you have watched endless videos on the best time to train, how long for and what food you should be eating. But it won’t be until you do that first ab crunch – which lets face it, won’t be perfect, that you will embark on your journey to achieving that six pack.

So my advice to you is – pause the video tutorial and build something. Apply what you have been learning and let go of the idea that it will be perfect. What is perfect today can be improved by your experiences tomorrow, the day after, in a year’s time and so on.

My second piece of advice – which is perhaps the one I am most passionate about as it forms the whole ethos of how I work: make it open source. I don’t want to assume that you know what open source is. It took me a few years into my career to find out about it. I was using open source tools in my day job and thinking how great it was that there were so many valuable free available tools out there that anyone could use. I was also beginning to network more and everyone kept talking about open source, which got me interested in finding out more about this community which works publicly and transparently to resolve software problems. I didn’t want to just take, I wanted to give back.

As a new developer you might be worried that you are not yet at a stage where you can give back and contribute. There is a misconception that you only have something to teach when you have reached a level of seniority in your career. But everyone has a voice. Don’t think that just because you are at the start of your career that all you should be doing is asking questions and seeking help. You do not want to be a drain on the community; at first you will get the help you need, but soon community members will see you are just there to get a quick fix to your problem and then drop off the face of the earth until you hit another stumbling block.

Beginning to get involved is not always easy – it might feel like you are entering an old fashioned boardroom meeting full of senior colleagues and you are under immense pressure to say something…anything at all… which really just contributes to you feeling anxious and insecure about your abilities and in a worse case, can stop you from taking that step.

So start small. Github in my view is a fantastic (and essential) way to start your journey into open source. Firstly, find a good repository:

  • Go to the Issues section which lists your issues, clear the search box;
  • Add the search parameter for the label “good first issue” and consider including a language;
  • This will list all issues which will match this criteria and from there have a look at the repositories and see which ones seem interesting to you.
  • Check the closed Pull Requests that have not been merged: it is completely acceptable for a project maintainer not to accept pull requests – but were these rejected in a friendly and constructive manner?
  • When making a contribution, focus on adding value (don’t just suggest a change for the sake of it) and being respectful towards the project maintainer’s time;
  • Bonus tip: check the insights tab on the repository to see if the project is inclusive for things like code of conduct.

You might ask – “But why should I make my projects open source?” Why would you not?

Is it because you hope your project will become your revenue stream and you do not want to share this with others? Making their project open source certainly did not hinder Red Hat when it was sold for £34 billion.

Is it because you lack the confidence and do not want to feel exposed? How else will you learn if you do not put yourself out there?

By making your project open source you widen the number of people you can learn from massively, as well as making connections which might even help further your career. When recruiting for my team I no longer spend hours quizzing a candidate about the bullet points in their CV. I go to their Github account where I can see exactly what they can do and how they interact with others.

Making your project open source is probably one of the best calling cards you can have as it showcases what you are about, not only from a technical perspective but also how you will engage with others. Whether you are looking for your first role as a developer, have secured one with a small start up or have embarked on a graduate training programme with one of the large tech companies, you need to know that no project is limited to one person only. You will need to collaborate with UI/UX, testers, product owners …the list goes on.

You may come across really well in a face to face (or virtual!) interview – exuding confidence and a team spirit. You also might not. By having an open source project your prospective employer and colleagues will be able to see how well you do with receiving and giving feedback and how you act upon this. This is a skill which needs to be learnt and open source projects are the forum to do it.

You might have a job where you work your own, or perhaps you work in a team with quite similar views and levels of seniority – these things might not be conducive to receiving and giving feedback.

By making your project open source you are interacting with people from all over the World, with different levels of seniority and most importantly different perspectives. That, New Developer, can only be a positive for your technical and personal development.

— Eddie

Eddie Jaoude is an open source advocate and believes open source is for everyone. Check out his GitHub and YouTube.

Google can’t help if you don’t know the words

Dear new developer,

If you don’t know what you don’t know, it’s hard to learn it. There are so many resources for learning, but if you can’t find them, you’re going to have a hard time taking advantage of them. Sometimes you need to spend time learning what you need to spend time learning. That is to say, you need to learn the broad outlines of a segment of knowledge before diving in.

This time spent prepping your understanding of swathes of a domain will be useful because it will accelerate your learning in the future, letting you grasp concepts and find resources more quickly.

Let’s say I got hired by a company to write a compiler, which would be a new area of software for me. Here are some things I would do if I were trying to learn this new domain.

Glossaries

I’d look for some glossaries about compiler design. Here’s the first result from Google when I search for “compiler design glossary”. Reading this would help me understand the meaning of words I might know from other contexts, such as “array” and “value”, but would encounter when reading more about compilers. Knowing the jargon of a domain is extremely helpful when you are searching to see whose shoulders you can stand on, as well as communicating with your team members.

Pattern match

Matching patterns is something I’ve done many times. I take something I understand fairly well and see whether it matches up to a new concept, domain, or technology. In this case, I might read about a compiler for parsing regular expressions. I understand how regular expressions work as an end user, so it won’t be as much of a leap as if I were to try to study a compiler for C. Here’s a search result that I might work through.

Books and videos

If I have time, books and videos can be very helpful at getting a wider view of a domain. Sometimes it’s hard to know which book or video to invest your time in. By looking at reviews on sites like Amazon and Youtube, you can leverage the wisdom of many people. I’d probably start with one of the top books here, were I to need to jump into compiler design. When I do this, I don’t feel the need to read the entire book or watch every minute of the video.

Twitter

You can use Twitter to “get smart quick” too. Basically, you can follow folks who are highly regarded by other folks in the same domain. Wesley did a great job of explaining it, so I’ll just point you to this video. You want to watch between 15:53 and 20:00, where he talks about getting smart around “quantum computing”. Once you know who to follow on Twitter because they are respected by the community, you can start figuring out the words and concepts they use.

Follow some rabbits down holes

I’m a big fan of timeboxing investigations, and I always tell team members I am mentoring that they shouldn’t spin their wheels too long; far better to ask a team member. But sometimes, when you are exploring a new domain, you should spin your wheels a bit. Follow some paths and see if they end up where you thought, or if they were dead ends. In this stage of knowledge gathering, there are no wasted efforts. Any time you “waste” investigating or following some threads of discussion will compound and save you time in the future. Do take some notes, either mental or written (I like a blog post, as I did here). Don’t feel like you need to come up with any firm answers. And feel free to timebox it, just make the time limit higher than it would be if you were actually trying to solve a problem.

Take a class

One time I was working on a project at a real estate brokerage where we wanted to do statistical analysis on property data. I didn’t have much background on it, so I ended up taking a free class from Coursera. This is a substantial time investment, but for foundational knowledge that you can leverage across other parts of your life (I’m a lot more suspicious of stats I see now), the additional time can be worth it.

Pick the technique that resonates with you next time you have to get smart quickly about a topic or technology. Spend some time investing in your upfront knowledge and I promise it will pay dividends as you dig deeper.

Sincerely,

Dan

Why and how to improve your writing skills as a software developer

This is a guest post from Allie Cooper. Enjoy.

It’s one thing to be able to write good code, but professional written communication is something else entirely. The ability to efficiently and authentically communicate using written language is an often ironically underrated skill in software development.

This is something that new developers need to get over very quickly. “Obsessions with patterns and algorithms don’t serve anyone’s mission by themselves,” explains engineer and career coach Minh Pham. “While coding might be your latest skill set, it is by no means an engineer’s only skillset. Remember that at the end of the day, it doesn’t matter if your code is ugly, fancy, verbose or concise – the value you create matters. Strive to be an excellent communicator, a quality teammate, and an outstanding human.” In today’s increasingly digitized workplace, achieving these qualities means honing your professional written communication skills.

Writing is Essential to Software Development

Any veteran developer can tell you that non coding-related writing is part and parcel of the daily grind, which includes writing tons of bug reports, notes for yourself, documentation for co-workers, and other technical discussions over chat or e-mail. You might also be tasked with explaining technicalities in ways that can be easily understood by clients. And as Inc points out, all of this generates a permanent record of any and all significant ideas, incidents, and other facts pertinent to how you’ve handled the job. In software development, the way you write and communicate over work platforms defines a great majority of your work history.

While writing code defines your raw ability as a software developer, your written professional correspondence tells the story of your ability to work with others in an inherently collaborative and complex field. Today, the sudden digital migration brought on by the global health crisis has only made professional writing a more integral skill for thriving in the new and increasingly web-based workplace. This is as true for experienced developers as it is for those who are looking to pick up the skills necessary for the job, which brings us to our next point.

The Future of Coding Education is Written and Online

From basic coding courses to advanced degree programs, more and more future developers are learning essential skills through online means. And the pandemic has only increased their numbers. For instance, Code Platoon Coding Bootcamp online basic coding courses have allowed the U.S. Department of Veteran Affairs to continue offering software development skills training for veterans as well as their spouses. And for safety reasons, all classes have been moved online.

Meanwhile top universities have also made this switch to training software specialists online. Maryville University’s online masters in software development is an advanced degree program that’s 100% web-based as well, with the perspective of producing future software consultants, UX designers, web developers, and DevOps engineers. And while these programs do include video conferencing classes, the majority of the work is through written communication. As natives to online work, the developers trained in these online programs are already developing the writing skills necessary to thriving amid the current digital migration.

In short, the field of software development is only getting more competitive and web-based. And while there’s no shortage of genius code writers for companies to cherry-pick from online universities and coding courses, the combination of a great coder and a great online communicator remains rare.

Practice Makes Perfect

Whether you’re already coding for a living or still learning the skill, you already have plenty of opportunities to hone your professional writing skills. Strive to be succinct and straightforward with every chat message or e-mail before hitting send. Put yourself in other people’s shoes – think about how the message you wrote will affect you if you were the one to receive it. Remember that every unnecessary word only muddles already complex conversations about technical specifications. Grammar is important, but so is writing with the perspective of being as empathic and as concise as possible – which can also allow you to develop a writing style that won’t require grammatical gymnastics. Never play to your emotions and always write with a collaborative mindset. The better you can communicate with the written word, the more value you can bring to any software development effort.

Allie Cooper is a freelance tech writer who specializes in I.T. and software development. Her mission is to help software developers further their careers. In her free time she plays online chess and sails.

Learn in public

This is a guest post from Shawn Wang aka swyx. Enjoy.

Dear new developer,

If there’s a golden rule to learning, it’s this one.

You already know that you will never be done learning. But most people “learn in private”, and lurk. They consume content without creating any themselves. Again, that’s fine, but we’re here to talk about being in the top quintile. What you do here is to have a habit of creating learning exhaust. Write blogs and tutorials and cheatsheets. Speak at meetups and conferences. Ask and answer things on Stackoverflow or Reddit. (Avoid the walled gardens like Slack and Discourse, they’re not public.) Make Youtube videos or Twitch streams. Start a newsletter. Draw cartoons (people loooove cartoons!). Whatever your thing is, make the thing you wish you had found when you were learning. Don’t judge your results by “claps” or retweets or stars or upvotes – just talk to yourself from 3 months ago. I keep an almost-daily dev blog written for no one else but me.

Guess what? It’s not about reaching as many people as possible with your content. If you can do that, great, remember me when you’re famous. But chances are that by far the biggest beneficiary of you trying to help past you is future you. If others benefit, that’s icing.

Oh you think you’re done? Don’t stop there. Enjoyed a coding video? Reach out to the speaker/instructor and thank them, and ask questions. Make PR’s to libraries you use. Make your own libraries no one will ever use. Clone stuff you like. Teach workshops. Go to conferences and summarize what you learned. Heck, go back to your own bootcamp to tell alumni what’s worked for you. There’s always one level deeper. But at every step of the way: Document what you did and the problems you solved.

The subheading under this rule would be: Try your best to be right, but don’t worry when you’re wrong. Repeatedly. If you feel uncomfortable, or like an impostor, good. You’re pushing yourself. Don’t assume you know everything, but try your best anyway, and let the internet correct you when you are inevitably wrong. Wear your noobyness on your sleeve.

People think you suck? Good. You agree. Ask them to explain, in detail, why you suck. You want to just feel good or you want to be good? No objections, no hurt feelings. Then go away and prove them wrong. Of course, if they get abusive block them.

Did I mention that teaching is the best way to learn? Talk while you code. It can be stressful and I haven’t done it all that much but my best technical interviews have been where I ended up talking like I teach instead of desperately trying to prove myself. We’re animals, we’re attracted to confidence and can smell desperation.

At some point you’ll get some support behind you. People notice genuine learners. They’ll want to help you. Don’t tell them, but they just became your mentors. This is very important: Pick up what they put down. Think of them as offering up quests for you to complete. When they say “Anyone willing to help with ______ ______?” you’re that kid in the first row with your hand already raised. These are senior engineers, some of the most in-demand people in tech. They’ll spend time with you, 1 on 1, if you help them out (p.s. and there’s always something they want help on). You can’t pay for this stuff. They’ll teach you for free. Most people don’t see what’s right in front of them. But not you.

“With so many junior devs out there, why will they help me?”, you ask.

Because you learn in public. By teaching you they teach many. You amplify them. You have one thing they don’t: a beginner’s mind. You see how this works?

At some point people will start asking you for help because of all the stuff you put out. 80% of developers are “dark”, they don’t write or speak or participate in public tech discourse. But you do. You must be an expert, right? Don’t tell them you aren’t. Answer best as you can, and when you’re stuck or wrong pass it up to your mentors.

Eventually you run out of mentors, and just solve things on your own. You’re still putting out content though. You see how this works?

Learn in public.

— swyx

p.s. Eventually, they’ll want to pay you for your help too. A lot more than you think.

This post was originally published here.

swyx is a Senior Developer Advocate at AWS and author of The Coding Career Handbook.

How to say I don’t know

Dear new developer,

The honest truth is that you won’t know everything. No one does. The CEO, CTO, the team lead, that really smart senior developer on your team, none of them know everything. In fact, I bet if you asked any one of them if they’d been stymied in the past week, they’d reveal that yes, they ran into something they didn’t know how to do or how to approach.

Encyclopedic knowledge isn’t a good goal. You need to know how to figure things out. But when someone asks you “can you do X?”, you need to be prepared with the right answer, even if you don’t know how to do X. For example, I was tasked with setting up a static IP for a heroku application. I didn’t know how to do this. Rather than say “I don’t know how to do that”, I said “let me do some research and get back to you.” I also asked about deadlines and how high a priority this was.

I did some research, read some docs and came up with a proposed solution. I discussed it at standup with my team, including my boss, and we came up with a path toward implementation.

When you don’t know something, and someone asks you about it, there are a few things you must do.

First, you should tell them you don’t know. They might have some clues for you, or pointers to documentation. These can all accelerate your ability to do what is asked of you.

Depending on the situation, they may assume you know, based on their experience. For example, I work in the authentication space right now, with standards like OAuth and OIDC. When I first started, I had to ask what every piece of jargon meant, but after a few months I got up to speed. Now when I talk to other audiences, I need to be careful not to use too much jargon or assume what others know. One favorite technique I use is repeating back what someone said: “Can I repeat back to you what said to make sure I understand it? What I heard is that the OAuth code grant redirects to the client application after the user authenticates. Is that right?”

When you say “I don’t know” don’t stop there. Say “I don’t know, but I’ll find out.” Again, they may point you in a direction, but by adding that second clause, you indicate that you’ll solve this problem. You should also ask about timeline and priority if that hasn’t been communicated (by story points, a task tracker or in some other fashion).

Finally, do what you say you’re going to do. Find out what you didn’t know. Don’t be afraid to ask questions of your team members, spend time on the internet searching, set up your dev environment and tweak settings, brainstorm, get frustrated, and write down hypotheses that you can test out. All of these are techniques I’ve used in trying to figure things out.

Saying I don’t know, honestly, with a plan to remedy your ignorance, is a key part of being a software developer.

Sincerely,

Dan

You’re gonna be OK

This is a guest post from Jerome Hardaway. Enjoy.

Dear new developer,

So, you’re in the office, learning a million things a minute that you were never exposed to. Everyone around you seems super competent and you don’t want to take time away from them, but you have no idea what you’re doing. You feel like you should probably be a janitor instead of working on a million dollar web app. I’m here to tell you, you’re wrong.

Every person who seems competent has felt like you or still feels like you do, they are just better at hiding it. I know people who have been doing this work for years and feel silly at least once a week. Hitting your head against the tech wall is a rite of passage here and normal and whether they tell you or not, we have all been there. We have all either accidentally taken down prod, nuked the repo, felt lost, accidentally ran up the AWS bill, and just straight up sucked at this job. So long as you focus on having more good days than bad, you will be fine. More than that, you’ll do great, so relax cause we are all rooting for you.

— Jerome

Jerome Hardaway is a Developer Advocate at Quicken Loans and Executive Director at Vets Who Code, Where they help veterans get jobs in software by teaching them how to program for free.