Programming

No matter what you do, there is no shortcut to learn programming. Practice, ask and create things over and over again — It’s the only way you will get where you want to be. I promise you it will pay back eventually.

Amazon Corretto is a no-cost, multiplatform, production-ready distribution of the Open Java Development Kit ; Corretto comes with long-term support; Corretto is certified as compatible with the Java SE standard; And support popular OSs: Amazon Linux 2, Windows, and macOS. Amazon Corretto 8 is in Preview.

Programming language: Formal language that translates into instructions for the computer to do things.

Source code :  Files containing text in programming language specific format. Files are where the actual programming is done

Building/Compiling :  Transforming source code to machine readable format such as executables.

Debugging:  Finding out problems in the source code either with a debugger tool or some other debugging method

Open-source:  ”Open-source software (OSS) is computer software with its source code made available with a license in which the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose.” -Wikipedia

IDE:  Integrated Development Environment is an advanced text editor with support for compiling, debugging and other software construction related activities.

API :  Application Programming Interface. Set of defined methods that can be used to communicate between software components

UML — Unified Modeling Language. Modeling language that is used to visualize architecture of a system in a standard way

SQL — Structured Query Language. Used to manage data in relational databases

Hello World The future of work will be very different. Irrespective of your job, it will become important for everyone to learn how to code.

Coding helps enrich your computational thinking, which is powerful in making decisions.

The traditional resume will go away and hiring will happen based on your skills first.

Did you know that 1 in 4 developers learned to code before they could drive?

It’s never too early — or too late! — to start coding.

All the developers who started coding after the age of 26, 36% are now senior or even higher-level developers, growing quickly in their careers.

Of the roughly 39,000 developers surveyed across all professional levels, more than a quarter of developers wrote their first piece of code before they were 16 years old.

Of the 17 countries represented in the survey with at least 100 respondents, the UK stands out with the highest share of developers who started coding as young as 5 to 10 years old. The majority of those developers are in their 30s and 40s today.

Nearly all developers have an insatiable thirst for learning

On average, developers know 4 languages, and they want to learn 4 more. The degree of thirst for learning varies by generations — young developers between 18 and 24 plan to learn 6 languages, whereas folks older than 35 only plan to learn 3.

Since programming is centered on independent research aimed at solving new challenges, self-teaching is a major part of being a successful developer.

In choosing what to learn next, the best guiding principle is to plant yourself in one discipline and learn tools as a means to grow. Tools will always change. Ultimately, it’s curiosity and genuine interest in programs that should fuel the drive to learn new tools and adapt to tech’s evolving landscape.

Developers are learning the languages employers are looking for most.

When you compare the most in-demand languages by employers with that of the most common languages that developers know, there is no gap. Java, JavaScript, C and C++, and Python all top the list of languages developers know.

Java, has been popular in the world of financial services for years. C dominates hardware because of its performance, direct low-level hardware API, and availability of compilers across many platforms. And C# is more common among government organizations.

Programming languages aren’t adopted in the industry as quickly as they are created, but JavaScript is changing the game with its frameworks.

A number of the most in-demand frameworks are JavaScript frameworks — it’s the only language versatile enough to build frontend, backend, mobile and browser extensions.

Hence, JavaScript is ruling the web. Most often, employers want developers who know AngularJS, Node.js, and React.

There’s a big opportunity for developers to learn React as a marketable skill that companies need today.

React has the biggest delta between percentage of developers who know the framework and percentage of employers who look for candidates with this skillset.

Almost all employers prioritize problem-solving skills first.

Problem-solving skills are almost unanimously the most important qualification that employers look for….more than programming languages proficiency, debugging, and system design.

Smaller companies look for framework proficiency in candidates more than medium-sized to large companies.

What you do matters more than what’s on your resume There's a popular belief that recruiters favor candidates with CS degrees from prestigious universities. But it turns out that they actually care about what you've done — not where you went to school.

An overwhelming majority of hiring managers said they look for proven skill, such as previous work, years of experience, and projects/GitHub.

Qualifications that generally bolster the resume (prestige of degree, education level, skill endorsements or certificates) rank the lowest among what companies care about the most.

Companies are looking at GitHub and projects to supplement resumes and evaluate skills better. C-level positions, including founders, CTOs and VPs, valued GitHub projects more than years of experience. Prestige of degree dropped even further in importance for these folks.

Google’s Go offers high concurrency, fast compilation and, of course, widespread support from its creator.

Google also spurred the use of Kotlin when it moved its canonical Android language away from Java.

Python is the one, JavaScript may be the most in-demand language by employers, but Python wins the heart of developers across all ages, according to our Love-Hate index. Python is also the most popular language that developers want to learn overall, and a significant share already knows it.

Python is known for its simplicity, readability, and vast possibilities of scientific libraries. It’s also growing as part of introductory computer science courses.

Younger developers dislike newer languages (like Go, Kotlin, and Scala) more so than older developers. In fact, Go creates one of the greatest divides. Developers aged 18-24 don’t care for it, but 45-54 year-olds consider it one of their most loved languages. The inverse is true about JavaScript.

Node.js is the newest jamNode.js wins as most loved framework by the largest share of developers.As the only method for backend JavaScript, Node.js is favored across all ages.

VIM for the win VIM beats all other editors by a landslide. Fans say its powerful keyboard commands are a crucial component of why it’s loved by developers everywhere.

Programming is mostly about reading previous code, researching what is needed and how it fits with the current system, and planning the writing of features with small, testable increments. The actual writing of lines of code is probably only 10% of the whole process.

Do not think about programming as writing lines of code. Programming is a logic-based creativity that needs nurturing.

Planning before jumping into code is a good thing, but even good things can hurt you when you do too much of them. Too much healthy water might poison you.

Do not look for a perfect plan. That does not exist in the world of programming. Look for a good-enough plan, something that you can use to get started.

The truth is, your plan will change, but what it was good for is to force you into some structure that leads to more clarity in your code. Too much planning is simply a waste of your time.

Always plan your next few features. Do that very carefully because too little planning and too much planning can both hurt the quality of your code. The quality of your code is not something you can risk.

If you can only focus on one aspect of the code that you write, it should be its readability. Unclear code is trash. It is not even recyclable.

Look at coding as a way to communicate implementations. Your main job as a coder is to clearly communicate the implementations of any solutions that you are working on.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.— John Woods

There are only two hard things in Computer Science: cache invalidation and naming things. — Phil Karlton

Do not use clever one-liners and nested ternary expressions just to keep the code shorter, but also do not intentionally make the code longer when it does not need to be. Deleting unnecessary code is the best thing you can do in any program.

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

The excessive use of conditional logic. Most of what you think needs conditional logic can be accomplished without it. Consider all the alternatives and pick exclusively based on readability.

Do not optimize for performance unless you can measure.

There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

Your job as a professional programmer is not to find a solution to the problem. It is to find the simplest solution to the problem that work correctly and perform adequately but still simple enough to read, understand, and maintain.

A mistake newbies make is sticking with the first solution even after they identify that it might not be the best approach.

The minute you begin doubting a solution, you should consider throwing it away and re-thinking the problem. This is true no matter how much you were invested in that solution.

Source control tools like GIT can help you branch off and experiment with many different solutions. Do not be attached to code because of how much effort you put into it.

There has been many instances where I wasted precious time trying to solve a problem when I should have just researched it. Unless you are using a bleeding-edge technology, when you run into a problem, chances are someone else ran into the same problem and found a solution for it.

The use of the encapsulation concept is always useful. Not using encapsulation often leads to harder-to-maintain systems.

A feature should have only one place in the code that handles it. That is usually the responsibility of a single object.

An object should only reveal what is absolutely necessary for other objects of the application to use it. This is not about secrecy but rather about the concept of reducing dependencies between different parts of an application.

Conceptual units of logic and state should get their own classes. This can be an actual Class object or a Function object. You might also identify it as a Module or a Package.

Within a class of logic, self-contained pieces of tasks should get their own methods. Methods should do one thing and do that thing well.

If you see a Util class that has been used as a dumping ground for many things that do not belong together, that is a sign of newbie code.

Your code must have High Cohesion and Low Coupling, which is just a fancy term that means keep related code together (in a class) and reduce the dependencies between different classes.

It is often tempting to think beyond the solution that you are writing. All sort of what-ifs will pop into your head with every line of code that you write. This is a good thing for testing edge cases, but it just wrong to use as a driver for potential needs.

Do not write code that you do not need today. Do not plan for the unknown future. Writing a feature because you think that you might need it in the future is simply wrong. Do not do it.

Always write the minimum amount of code that you need today for the solution that you are implementing. Handle edge-cases, sure, but do not add edge-features.

It is good to identify good algorithms and use them when needed, but memorizing them will probably never attribute to your programming genius.

Memorizing the strengths and weaknesses of the various data structures that you can use in your language will make you a better developer.

When writing any code that requires some form of recursion, it is a lot easier to just use the concept of recursion. However, it is usually hard to optimize recursive code, especially in single-threaded environments.

What beginners often forget is that there is an alternative to recursion. You can just use a Stack structure. Push function calls to a Stack yourself and start popping them out when you are ready to traverse the calls back.

I avoid writing comments when I can. I think most comments can be replaced with better named elements in your code.

Just using better names for functions and arguments simply makes most comments unnecessary. Keep that in mind before writing any comment.

Sometimes you are forced into situations where the only clarity you can add to the code is via comments. This is when you should structure your comments to answer the question of WHY this code rather that the question of WHAT is this code doing.

I am going to keep this point simple. If you think you are an expert programmer and that thinking gives you the confidence to write code without tests, you are a newbie in my book (literally).

You should manually test your code only to figure out how to automatically test it. If you successfully test an interaction with your application, you should go back to your code editor and write code to automatically perform the exact same interaction the next time you add more code to the project.

You are a human being. You are going to forget to test all previously successful validations after each code change. Let the computer do that for you!

If you can, start by guessing or designing your tests even before you write the code to satisfy them. Testing-driven development (TDD) is not just some fancy hype. It positively affects the way you think about your features and how to come up with a better design for them.

As a beginner, you should just assume that any code that you do not understand is a candidate for being bad. Question it. Ask about it. git blame it!

The term best practices is actually harmful. It implies that no further research is needed. There are no best practices, there are probably good practices today and for this programming language. Some of what we previously identified as best practices in programming are labeled today as bad practices.

You can always find better practices if you invest enough time. Stop worrying about best practices and focus on what you can do best. The only valid best practices in coding are the generic ones. For example, write the highest quality code than you possibly can.

Do not do something just because of a quote you read somewhere or because you saw someone else do it, or because someone said this is a best practice!

Premature optimization is the root of all evil (or at least most of it) in programming — Donald Knuth (1974)

The good rule to remember about optimization is: if you cannot measure the suspected efficiency problem with the code, do not attempt to optimize it, and if you are optimizing even before writing the code, chances are you are doing it prematurely.

Any non-obvious optimization that is carried out on any existing code without measurements is considered harmful and should be avoided. What you think is a performance gain might turn out to be a source of new, unexpected bugs.

There are some obvious optimizations that you should always consider before introducing new code. For example, in Node.js, it is extremely important that you do not flood the event loop or block the call stack. So ask yourself: Will the code I am thinking about block the call stack?

Be one of the professional developers who put themselves in their end-users' shoes. They think about the ways to make the feature easy for the end-users to find and use, not about the easy way to make the feature exist in the application somehow without any thoughts about that feature’s discoverability and usability.

A hammer is a great tool to drive a nail into a wall but it is the worst tool to use with a screw. Do not use a hammer on a screw just because you love that hammer. Do not use a hammer on a screw just because that is the most popular hammer on amazon with 5.0 user reviews.

Within your current knowledge, a tool might be the best tool that you know of. However, when compared to other options, it would not make the top list. You need to familiarize yourself with the tools available to you and keep an open-mind about the new tools that you can start using.

Some coders refuse to use new tools. They are comfortable with their existing tools and they probably do not want to learn any new ones. I understand that and I can relate to it, but it is simply wrong.

You can build a house with primitive tools and take your sweet time or you can invest some time and money in new super-tools and build a better house much faster. Tools are continually improving and you need to get comfortable learning about them and using them.

When your program is about managing some kind of data the smallest bugs in the program’s code will result in an unpredictable state for the data it manages. This is especially true if all validations on the data are done entirely through the same buggy program.

How to protect the data integrity? You can simply use multiple layers of data integrity validations. Do not rely on the single user interface. Create validations on front-ends, back-ends, network communications, and databases. If that is not an option, then you have to at-least use database-level constraints.

Another newbie problem that is related to data integrity is the lack of thinking in terms of transactions. If multiple operations need to change the same data source and they depend on each other, they HAVE to be wrapped in a transaction that can be rolled back when one of these operations fail.

In programming, some wheels are simply worth reinventing. Programming is not a well-defined domain. So many things change so fast and new requirements are introduced faster than any team can handle.

If you need a wheel that spins at different speeds based on the time of the day, instead of customizing the wheel we all know and love, maybe we need to rethink it. However, unless you actually need a wheel that is not used in its typical design, do not reinvent it. Just use the damn wheel.

Do not spend your precious time researching which is the best wheel out there. Just do a quick research and use what you find. Only replace wheels when you can clearly see that they do not perform as advertised.

The cool thing about programming is that most wheels are free and open sourced for you to see their internal design. You can easily judge coding wheels by their internal design quality.

Use open-source wheels if you can! Open-source packages can be debugged and fixed easily. They can also be replaced easily. In addition, it is easier to support them in-house.

However, if you need a wheel, do not buy a whole new car and put the car that you are maintaining on top of that new car. Do not include a whole library just to use a function or two out of it.

Look at every code review as a learning opportunity. Welcome them and appreciate them. Learn from them. And most importantly, thank your reviewers when they teach you something.

If something was not obvious from just your code, then maybe your code needs to be modified in that case.

Teaching is one of the most rewarding activities that you can do as a programmer. Look at me! I dedicated more than half of my working time to teaching. Do you think I do that just for the money?

Source control is not about just pushing your changes for others to have and build on. It is a lot bigger than that.

Source control is about clear history. Code will be questioned and the history of the progress of that code will help answer some of the tough questions. This is why we care about commit messages.

VCS (Version Control System) are yet another channel to communicate your implementations and using them with small commits help future maintainers of your code figure out how the code reached the state that it is in right now.

Commit often and commit early and for the love of consistency use present tense verbs in your commit subject line. Be detailed with your messages but keep in mind that they should be summaries. If you need more than a few lines in them, that is probably a sign that your commit is simply too long. Rebase!

Do not include anything unnecessary in your commit messages. For example, do not list the files that were added, modified, or deleted in your commit summaries. That list exists in the commit object itself and can be easily displayed with some Git command arguments.

The use of Git features like staging changes, patching selectively, resetting, stashing, amending, applying, diffing, reversing and many others add some rich tools to your coding flow. Understand them, learn them, use them, and appreciate them.

Errors are a good thing. They mean you are making progress. They mean you have an easy follow-up change to make more progress. Expert programmers love errors. Newbies hate them.

If seeing the wonderful little red error messages bother you, you need to change that attitude. You need to look at them as helpers. You need to deal with them. You need to leverage them to make progress.

You are a human and your brain needs breaks. Your body also needs breaks. You will often be in the zone and forget to take breaks. This is not something you can compromise.

Integrate something (as: Pomodoro Technique) in your workflow that forces you to take breaks. Take a lot of short breaks. Leave your chair and take a short walk and use it to think about what you need to do next. Come back to the code with fresh eyes.