2020 is already more than half-way gone but with so much happening this year (COVID-19, anyone?), we at Codota only just now got around to compiling our list of top devs to follow this year.
As we’re becoming more and more involved in the dev community and engaging with our coders (we prefer that over “users”, what do you think?), we’ve found so many great people who dedicate their precious time to educate, influence, and share insights with their followers and the wider community.
Getting around this endless network of talented developers is challenging in itself, so, we did some digging for you and created this list of our top 14 favorite influencers in software development for 2020 – in no particular order.
Chances are you’ve clapped for one of Javin’s articles on Medium before. Javin is a Java Programmer and Blogger, with a strong and engaged social following of tens of thousands both on Twitter and Medium.
He’s been writing Java articles and tutorials for the last 10 years, on his blog Java Revisited, and coding Java for 15 years. The team at Codota especially likes his clever, insightful, and humorous tweets, so we encourage you to check him out!
You can check out the latest on http://javarevisited.blogspot.com and http://java67.com
Ania Kubow is a Software Developer and popular YouTuber specializing in recreating some of the most popular and classic retro games using pure JavaScript, HTML, and CSS.
Her passion lies in helping others learn the fundamentals of JavaScript, as well as logical thinking. Outside of her own YouTube channel, you can also find her tutorials of the likes of Udemy, FreeCodeCamp, and many more.
Danny is a thought leader and software engineer who provides his large and admiring fanbase with more that just code tutorials. Danny also has a YouTube channel on how to find your next job on LinkedIn, and delivers an inspirational podcast for developers looking to hit their personal career goals.
Danny teaches, speaks at and organizes meetups, and is very much involved in community activity by trying to help young people to get high quality education.
Danny has a super fun Twitter page with almost 37K followers!
Angie is a Senior Developer Advocate who specializes in test automation strategies and techniques. She has a super cool website in which you can find her articles, courses, talks and workshops.
She shares her wealth of knowledge by speaking and teaching at software conferences worldwide, as well as on the leading online platform – Test Automation University.
In her spare time, Angie volunteers with Black Girls Code to teach coding workshops to young girls in an effort to attract more women and minorities to tech.
Cyris is a 100% self-taught full-stack developer from New Zealand, and he is not very far from reaching his 20K followers on Twitter. He started out coding HTML emails and moving onto Front-end development for websites. He’s been working in the Digital Marketing space for 10 years now, his preferred languages are JavaScript and using NodeJS for backend.
He likes to build and code Arduino, ESP32 robotics and projects, while enjoying his other hobby 3D Printing. If you’re looking for someone who to learn JavaScript from while having a good time then you should follow Cyris. The fact that he’s from New Zealand makes it that much cooler but luckily he’s got more things to offer 🙂
Trey is a software developer and founder of Skilled.dev and gitconnected.com. He started out as a self-taught engineer, over 6 years ago, and is passionate about building tools to help others launch their career in software engineering. Trey excels at teaching experienced developers how to land their dream job.
You might be familiar with Jhey’s bear more than you’re familiar with Jhey, so we’ve used a photo of them both. He’s a web developer with almost 10 years of experience (Jhey, not the bear), working with a variety of tools. Typically he’ll be digging in with React, architecting CSS in and out of JavaScript, or orchestrating slick animations with Greensock.
Nicola is both Italian and a software developer, which makes him almost perfect 🙂 Nicola loves to work with people and explore new experiences for personal growth.
When he was 10 years old, his father bought him his first personal computer, and since then he’s had a computer joined at the hip. Besides the fact that he is coding from Romeo & Juliet’s home town of Verona, he is a freelance developer, focused on JavaScript in general and Angular in particular, with great passion for technology and space rockets.
James is a developer, speaker, and teacher with a passion for web development, design and developer tools. He is a Senior Developer Advocate at Auth0 and has over 7 years of experience in advocacy and software development. In his spare time, he owns a YouTube channel, has created several courses on Node and React, plays co-ed soccer with his wife, spends time with his dogs, and can solve a Rubik’s cube in under two minutes.
Ravin is a self taught web developer with expertise in JavaScript, TypeScript, and Python, that, according to his Twitter bio, eats APIs for breakfast. Sounds yummy. Ravin is a freelancer, whose apparent love for Twitter polls creates some of the most fun Twitter threads a developer could ask for.
Marc is a freelancing, full-stack, web developer, extraordinaire. Despite his breadth of coding knowledge, Marc loves learning new things.
So here are a few new things you may not have known about Marc – He lives in Luxembourg, drinks Espresso, and enjoys travelling (once upon a time, when it was possible…).
He mostly works with JavaScript (Node.js & Vue.js), and also has experience with Ruby on Rails, PHP, and others. Don’t miss Marc’s funny dev related memes on his Twitter page!
Yannic makes videos on topics he loves :). His YouTube Channel, boasting over 34.1K subscribers, is chock full of machine learning related content. How deep does he go? Well, he even has videos where he reviews memes about machine learning. Usually sporting a pair of cool sunglasses, no one makes machine learning as cool as Yannic.
Rachit is a MicroSoft dev based out of Hyderabad. He also happens to own a popular YouTube channel with 120K programmers subscribed (!). His channel is a blend of programming tutorials, life lessons, and mentorship talks.
Like some of the other influencers on this list, Rachit aspires to help devs reach their goals. He believes that “Everyone should get a chance in their lifetime to feel proud of themselves”, and works hard to guide the young minds across the entire world.
Roman is a computer scientist at the University of Louisville, known for his work on behavioral biometrics, security of cyber worlds, and artificial intelligence safety.
Roman is currently the director of Cyber Security Laboratory in the department of Computer Engineering and Computer Science at the Speed School of Engineering. Although is dealing with very serious things, you can enjoy his fine humor on his Twitter page.
The age of remote work is here.
Well, for many development teams, it’s been here for quite some time now. COVID-19 just helped us convinced the boss that you don’t need to be in the same room to make moving a project forward possible.
As the office moves away from physical spaces and adopting digital ones instead, your team might be part of the crowd that’s migrating towards a fully automated and remote workspace.
While we may cheer to no more traffic jams and long commutes, you’re still required to telecommute into the office via your Internet connection. Your team might already be remote – but not at the levels required to function as effectively as possible.
Here’s how to navigate remote work as a team and make sure that your projects continue to ship within a certain level of quality and on time.
If you’re working with an agile framework, there’s a high chance that you’ll have some sort of kanban board sitting in the office. Colorful sticky-notes plastered all over each column, each moving along the lanes as the project progressed in a particular direction. A sea of back-log and unscheduled tasks may sit somewhere nearby, with tickets lost or demoted down the priority list.
There’s something special about having a physical kanban board. The materialness of its presence makes it real against the intangible process of creating code.
As developers, when we make code, it’s hidden in between the forest of files, folders, curly braces and thought processes. A kanban board helps us visualize this.
When you move away from a physical office where everyone sits together in the same room, this board is no longer possible – unless you digitize it.
There are numerous ways to digitize a kanban board – but tickets are useless unless developers actually look at them. The purpose of kanban and agile is to give developers visibility and accountability.
The physical board is something that sticks out when you’re sitting in an office. It’s always there. Everyone knows its there. When someone walks past it, the tickets hold a particular weight of responsibility and ownership over them.
You can digitize everything – but if the workflow doesn’t endorse it, then trying to replicate a digital version of the office won’t work.
Going digital can cause havoc on this because it can take effort to see the kanban board. You have to make a conscious decision to go and look at it. So how do you fix them?
The easiest solution is to make it part of your workflow.
If your code workflow already sits with GitHub, there is a projects feature that allows you to set up lanes and ticket tasks with a kanban vibe. It doesn’t matter what you’re doing, if you’re already in GitHub to push, pull, review, approve or do something on the platform, you’ll find yourself looking at the digital board.
Its proximity to your work is akin to the physical proximity it had when you were sitting in the office with the rest of your team.
This may sound strange but when you reduce your deliverable size, you can fit more of them in a delivery cycle. While the actual workload might end up being the same, you’re going to need visibility and movement when you’re in a remote environment.
Teams often lose contact with one another once they go remote. There’s a chance that they can get lost in their own tickets and cease to communicate with one another. The bigger the ticket, the higher the chances of this occurring.
Unless you were originally remote by design, moving from a physical office into a remote space can cause result in broken communication and slower completion of deliverables. The transition phase is a precarious time and breaking down your deliverable size can help you determine your efficiency factor as a team.
Rather than banking on large chunks to be delivered, smaller tickets can mean you’re able to fine tune the burn down rate. It’ll also help you identify potential bottlenecks faster and therefore resolve issues as they turn up.
It increases the visibility of a potential issue as code gets pulled more for review and commits happen in an increased frequency. When issues turn up sooner than later, it facilitates earlier forms of communication.
The actual amount of work might end up being the same but the movement forward is much more granular in approach. When large tickets are broken down into smaller parts, it’s easier to replace or delegate the tasks between team members.
While communication is key to staying on the same page and making sure that everyone understands where they fit into the team and the work that’s expected – there is a thing as too much communication, especially in a remote and digital setting.
It’s easy to just walk up to another dev and ask for their help. It’s a bit different when you’re working remotely.
Keep your communications at a minimum and avoid long email chains that involve more than just the two people talking. Why? Once you add a third or fourth person, it’s easy to accidentally miss someone out in the chain or it becomes too long and hard to follow.
Tracing a conversation in emails can be a pain. The act of communication itself is not the issue. Rather, it’s the presentation of how emails work.
For official pieces of information where it won’t turn into a long chain, email is not bad. For conversations that requires bouncing back and forth, problem solving and collaboration – email is not the right tool.
Reducing points of digital contact can reduce the amount of time a developer needs to break away from the act of working to converse with their peers. Talking is not a bad thing. Spending time trying to figure out what everyone is thinking and finding out conclusions to conversations is where the time sinks happen.
Most of the time, your team only needs two things – a space where they can communicate and converse in an unstructured manner, and another to document and create progress tracking.
When you leave a team to self organize and facilitate the required communication channels to meet these two vital needs, remote work becomes a breeze. It will help maintain project clarity and ensure that everyone understands the what, the who, the when and the where things are happening.
Successful remote teams are often defined by their ability to remain organized through the communication and planning interfaces implemented. If your team is already working well in an office setting, then moving into remote work won’t be much different.
Developers are smart people by design and nature, with a good pinch of tech savviness to figure things out without the need for handholding. Most of the time, there just needs to be someone to monitor and ensure that communication stays open, frequent and organized enough that it doesn’t slow down the project deliverables.
Diligent cleaning and archiving of communication spaces is also required to prevent walls, threads and chats from being clogged up over time by past projects, tickets and discussions.
It’s also a good idea to let your teams be self organizing. It’s easy to try and enforce rules and methodologies on them – but developers are at ground zero of the code work.
They know what they need and will figure out the shortest path possible to get it. If a particular communication channel or methodology is working for them, don’t try to enforce something else into it, unless everyone agrees that it is better and more effective.
When you give a group of developers a set of clear requirements and flexible framework to deliver it, you give them the ability to think and grow as a team and as creative thinkers – especially in a remote environment.
There’s more to being a senior developer than just the number of years you’ve got under your belt. Just because you’ve been writing a particular language for a certain amount of time, it doesn’t default you into a true senior veteran. Age and length of time might contribute, but it’s not the final factor.
So what does it take to be a senior developer? What exactly do you need to know? Or is there some secret sauce that you need to dip into for qualifying as a senior veteran of code?
The difference between junior and intermediate developers is not that large. A junior might have just recently graduated or managed to finally get their foot into the door. It might be their first proper development job, building real software with other developers who know more than them.
It only takes a few intense projects to qualify as an intermediate developer. It might be within six months to a couple of years, but the act of moving up the organizational ranks – either through promotion or job change – is very easy.
And this is where many developers tend to get stuck. They’ve defaulted into the intermediate role because of job experience – but at what point is it considered enough to be a senior developer?
An intermediate developer can construct proficient code. A senior developer knows how to architecture it.
If you think about the difference between the bricklayers and the architect, intermediate developers often perform tasks that follows a particular structure or plan. Senior developers tend to move between the code and, using their expansive knowledge, connect the right dots.
While intermediate developers can construct blueprints and plans of their own, senior developers tend to focus on patterns and future implications.
They’re forward-thinking in their approaches, and have experienced the fine line between factoring in all the potential outcomes vs. the demands required to be delivered.
And it doesn’t take them long to make a decision.
The dots that they have at their disposal are wide in topics and areas, ranging from a myriad of stories, articles and many things they read and consume. They are constant learners and consumers of knowledge, and know how to apply them in the right moments. Their learning may be structured and linear for certain aspects, but a lot of the learn is deconstructed and ad-hoc.
The ad-hoc nature of knowledge acquisition gives them an edge over their intermediate counterpart. How? because the senior developer have more dots to join to form a better and more cohesive picture of the technical requirements, pinpoint potential weaknesses and architecture in strength and robustness.
The idea of the senior developer is a bit of myth in itself. While the title is good for management and pay scales, as we move through the different languages, releases, packages, updates and upgrades – the scope of being a developer can never truly be defined.
This means that you can’t possibly put a developer on a scale of how much mastery they’ve got over a particular sphere or area of their chosen language. At some point, other languages and technologies will find its way into the senior developer’s peripheries.
Regardless of knowledge depth, breadth and experience – you’re always going to be a junior at something.
The senior veteran of code acknowledges this. They understand that they may be a senior in one specific area of code development, but it doesn’t automatically give them seniority in everything. This is often a misconception that many juniors and entrants into the industry have.
Juniors tend to make judgements based on the number of years rather than the intensity and depth of a particular project – or series of projects. That’s why agile projects tend to upgrade a developer’s professional development faster than other forms of project management.
When you’re working in an agile environment, you’re forced to learn quickly and apply your learnings.
Experiencing a lot of projects in succession doesn’t exempt you from the depth factor. Depth of knowledge runs beyond the ability to create code. It also includes the ability to create code in that succinctly beautiful.
What does beautiful code look like?
This one is debatable. But if you think about it this way – anyone can write code. But to write code that works, has the ability to withstand changes, remain stable after core and package upgrades, among many other things – that takes skills and foresight.
Gaining this skill might be in the form of previously encountering errors, bad architecture and finding solutions to them. Not everything is a greenfield kind of project and a senior veteran of code is often marked by the past code of others – some good, some bad, some in the form of nightmarish code that smells so bad that it’s beyond salvageable.
This is a facet of coding that only senior veterans of code experiences in large volume. It’s part of the job. it is also something that not many non-technical interviews pick up on. They may look at other markers such as years or length of tenure instead.
They do this because it is the same markers often used in other areas of the business world. However, potential future fellow team members can sense a developer’s seniority based on how they interact with others and the way they analyze code.
A junior developer is often preoccupied with perfect code. An intermediate developer tend to focus on the idea of ‘clean code’. A senior developer will go down the path of balanced and working code. Balance comes in the form of weighing up the needs of the business and the needs of the system, and finding the right solution to bridge both worlds into the same universe.
To get to the final stage, here are few things that can help get you there.
Being a senior developer is more than just the code. It’s about the depth and understanding of the code presented. It’s also about the ability to see into the future, with an educated guess of how things will fall apart and withstand changes.
Change is one of the main reasons why code becomes brittle and needs maintenance. But change is necessary and part of every business. A senior developer understands this. They embrace it with open arms and accept that they will also need to grow their techniques toolkit, adapt, and continuously learn in order to remain on top of the change.
Java is a “mature” language with traditions and rituals that can be compared to those of a religion. Just check out Reddit discussions on Java vs {{insert backend language here}}. As widespread as it is, the religion that is Java is a living and breathing faith with an active community, ever-changing and developing.
Some still recite prayers from ancient releases while others are eager to adopt new customs. One such custom, introduced with Java SE 8, is the use of Lambda expressions – a concept adopted from the realm of functional programming.
For seasoned practitioners of Java (also known as senior developers) accustomed to an object oriented approach, Lambda expressions may seem at first glance like some form of blasphemy. The OOP tradition is to execute functions only after defining them inside a class, then creating an object of the class to call the method. If it works, why fix it, right? Wrong.
Lambda expressions can make your code easier to understand, faster to write, and potentially less painstaking to maintain. If you’re not making use of them yet, perhaps now is a good time to take a leap of faith and learn how lambda expressions can make your code (and thus your life) better.
The concept of Lambda expressions was first introduced in the LISP programming language. In Java, Lambda expressions were added in Java SE 8. This was Java’s first step into functional programming and perhaps the most impactful feature added to the programming language with the Java SE 8 release.
Lambda expressions are essentially a block of code (an anonymous function) that can be passed to constructors or methods for subsequent execution. The constructor or method receives the Lambda as an argument.
Lambda expressions are primarily used to implement the abstract function of a functional interface (a class with a single abstract method only). Especially useful in collection libraries, Lambda expressions help iterate, filter and extract data from a collection. In addition, since Java Lambda expressions are treated as functions, the compiler does not create .class files for them.
In terms of implementation, Lambda expressions enable three main capabilities:
The syntax for Lambda expressions is surprisingly simple and flexible. To create a Lambda expression, just specify input parameters (if you want to – it’s not mandatory), the Lambda operator ->, then enter the expression or block of statements.
(arguments) -> {function body}
Java Lambda expressions consist of three components.
(Source: educative.io)
For example, the Lambda expression (a, b) -> {a + b} will receive arguments a and b to return their sum. Of course, it can get a lot more complicated fairly fast.
Generally speaking, Lambda expressions make for cleaner, shorter and more readable source code with less obfuscation. How? By providing a smarter way to implement functional interfaces.
Back in the olden days before Java SE 8, when you needed to pass functionality to a method, you would use an anonymous class. This meant you would then have to define the method again to provide implementation instead of just implementing. To mitigate this issue, Java 8 introduced Lambdas. Their main objective? To actively increase the expressive power of Java as a programming language.
To better understand the benefits of Lambda expressions, it’s worth comparing them against methods in Java.
A method (or function) in Java has a few mandatory components: name, arguments (parameters), function body and return type. Lambda expressions have no names, nor do they specify the return type. Instead, the Java compiler is able to infer the return type by inspecting the function body and without explicit mention. Also, it doesn’t require the type of the method argument. Pretty smart, right?
A simple example for Lambda, would be using it instead of an anonymous Comparator. Suppose we have a Dish defined as such:
class Dish{
int id;
String name;
float price;
public void printDish() {
//...
}
}
Sorting a List of those Dishes can be done with an anonymous Comparator as such:
public static void anonymousComparatorSort(List<Dish> list) {
Collections.sort(list, new Comparator<Dish>() {
@Override
public int compare(Dish p1, Dish p2) {
return p1.name.compareTo(p2.name);
}
});
}
Which can also be done using a simple Lambda Expression:
public static void lambdaSort(List<Dish> list) {
Collections.sort(list,(p1,p2)->{
return p1.name.compareTo(p2.name);
});
}
Not a lot of code lines have been saved by this transition, only the definition of the anonymous class. This is the simplest of examples. The Comparator interface is already defined, but what if we have an example where the interface has yet to be defined?
Suppose instead of sorting a List, you would like to print all Dishes above a certain price. We will use the same Dish from earlier and define our search method using an interface and an anonymous class.
This will be the interface that defines the criteria of the search:
public interface DishCheck {
public boolean test(Dish dish);
}
And this will be the printing method that will take int a DishChecker and print all dishes that pass the check.
public static void printDishes(List<Dish> list, DishCheck tester) {
for (Dish dish : list) {
if (tester.test(dish)) {
dish.printDish();
}
}
}
Using the above method will require implementing an anonymous class when called:
public static void main(String[] args) {
List<Dish> list = new ArrayList<Dish>();
//Populate the list
//Print dishes with price equal to or greater than 4.5
printDishes(list, new DishCheck() {
@Override
public boolean test(Dish dish) {
return dish.price >= 4.5;
}
});
}
It is possible to bypass the anonymous class with Lambda the same way we did earlier with the Comparator:
public static void main(String[] args) {
List<Dish> list = new ArrayList<Dish>();
//Populate the list
//Print dishes with price equal to or greater than 4.5
printDishes(list, (d1) -> {
return d1.price >= 4.5f;
});
}
Or we could completely bypass the printDishes method and write it directly into the Lambda using the collections forEach method:
public static void main(String[] args) {
List<Dish> list = new ArrayList<Dish>();
//Populate the list
//Print dishes with price equal to or greater than 4.5
list.forEach(d1 -> {if (d1.price >= 4.5) d1.printDish();});
}
This is done by allowing the Lambda expression to implement the Consumer Interface, a powerful tool that can allow an action to be performed on an item in the list.
It is also possible to write a more elaborate method that will allow using both a tester and a consumer on the list. Instead of the printDishes method, consider the following:
public static void takeActionOnDishes(
List<Dish> list, DishCheck tester, Consumer<Dish> action) {
for (Dish dish : list) {
if (tester.test(dish)) {
action.accept(dish);
}
}
}
Now when you call the method, you not only specify the criteria for the action, but also which action will be taken:
public static void main(String[] args) {
List<Dish> list = new ArrayList<Dish>();
//Populate the list
//Print dishes with price equal to or greater than 4.5
takeActionOnDishes(
list,
(d1) -> {return d1.price >= 4.5f;},
(d1) -> {d1.printDish();}
);
}
Readable and maintainable code makes for happy developers and dev team leaders. When it comes to Java, Lambda expressions are one of the tools added to the language to enable just that by borrowing functionality from functional programming languages.