Programming Language

From BC$ MobileTV Wiki
(Redirected from Programming)
Jump to: navigation, search

A Programming Language is a formal language and method of controlling a machine (or type of machines) using instructions.


The following categories represent the most popular types of programming languages in existence today:

Paradigms

Imperative

  1. Ruby
  2. C#
  3. ASP
  4. JSP
  5. PHP
  6. Python
  7. Perl

Logical

  1. Prolog
  2. F-logic
  3. Rule bases (for running Rule Engines)

Procedural

  1. C
  2. Bash/Shell
  3. Batch/Powershell scripts
  4. IBM RPG

Object-Oriented

  1. Java
  2. C++
  3. Smalltalk

[1]

Declarative

  1. Groovy (DSL syntax)
  2. Lisp
  3. SQL
  4. SPARQL
  5. CSS
  6. HTML/HTML5
  7. XML/xHTML
  8. YAML

[2] [3] [4] [5] [6]

Fluent

  1. jQuery

[7]

Functional

  1. JavaScript
  2. Scala
  3. LISP
  4. Assembly Language
  5. Machine Language
  6. APL

[8] [9] [10]

Reactive

  1. Swift
  2. Kotlin
  3. Rx (various cross-platform libraries)

[11] [12]


Code Metrics

Software Quality Attributes (commonly abbreviated SQA) may potentially display visible symptoms externally when there are issues, but the argument of those who closely measure, monitor and maintain Code Metrics believe the roots of such problems are commonly invisible internal quality attributes such as: program structure, complexity, coupling, testability, reusability, readability, maintainability. There are many possible metrics to look into, however it is commonly accepted that Coupling, Complexity, Cohesion and Size are the fundamental internal quality attributes of a software program.

There are many ways of measuring and assessing these 4 fundametnal SQA, for instance, the following are the Code Metrics measured by CodeMR tool, which has become one of the leading OSS options (with a basic free product and more comprehensive commercial offering):

  1. Coupling - aim for lower coupling (impact of changes in one area to other areas, unintended side-effects, etc)
  2. LCohesion - Lack of Cohesion measures how well the methods of a class are related to each other. High cohesion (low lack of cohesion) tend to be preferable, because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability. In contrast, low cohesion is associated with undesirable traits such as being difficult to maintain, test, reuse, or even understand.
  3. Complexity - Implies being difficult to understand and describes the interactions between a number of entities. Higher levels of complexity in software increase the risk of unintentionally interfering with interactions and so increases the chance of introducing defects when making changes.
  4. Size - one of the oldest and most common forms of software measurement. Measured by the number of lines or methods in the code. A very high count might indicate that a class or method is trying to do too much work and should be split up. It might also indicate that the class might be hard to maintain.
  5. CLOC - Class Lines of Code measures the number of all nonempty, non-commented lines of the body of the class. CLOC is a measure of size and also indirectly related to the class complexity.
  6. WMC - Weighted Method Count is the weighted sum of all class’ methods and represents the McCabe complexity of a class. It is equal to number of methods, if the complexity is taken as 1 for each method. The number of methods and complexity can be used to predict development, maintaining and testing effort estimation. In inheritance if base class has high number of method, it affects its' child classes and all methods are represented in sub-clasess. If number of methods is high, that class possibly domain spesific. Thefore they are less reusable. Also these classes tend to more change and defect prone.
  7. DIT - Depth of Inheritance Tree is the position of the class in the inheritance tree. Has 0 (zero) value for root and non-inherited classes.For the multiple inheritance, the metric shows the maximum length. Deeper class in the inheritance tree, probably inherit. Therefore, it is harder to predict its behavior. Also this class relatively complex to develop, test and maintain.
  8. NOC - Number of Children is the number of direct subclasses of a class. The size of NOC approximately indicates how an application reuses itself. It is assumed that the more children a class has, the more responsibility there is on the maintainer of the class not to break the children's behaviour. As a result, it is harder to modify the class and requires more testing.
  9. CBO - Coupling Between Object Classes is the number of classes that a class is coupled to. It is calculated by counting other classes whose attributes or methods are used by a class, plus those that use the attributes or methods of the given class. Inheritance relations are excluded. As a measure of coupling CBO metric is related with reusability and testability of the class. More coupling means that the code becomes more difficult to maintain because changes in other classes can also cause changes in that class. Therefore these classes are less reusable and need more testing effort.
  10. CBO_LIB - The number of dependent library classes.
  11. CBO_APP - The number of dependent classes in the application.
  12. RFC - Response For a Class is the number of the methods that can be potentially invoked in response to a public message received by an object of a particular class. It includes the full call graph of any method called from the originating method.If the number of methods that can be invoked at a class is high, then the class is considered more complex and can be highly coupled to other classes. Therefore more test and maintain effort is required.
  13. SRFC - Simple Response For a Class is the number of the methods that can be potentially invoked in response to a public message received by an object of a particular class. It includes methods directly invoced from the class. If the number of methods that can be invoked at a class is high, then the class is considered more complex and can be highly coupled to other classes. Therefore more test and maintain effort is required.
  14. LCOM - Lack of Cohesion of Methods measures how methods of a class are related to each other. Low cohesion means that the class implements more than one responsibility. A change request by either a Bug or a new feature, on one of these responsibilities will result in a change of that class, which greatly increases likelihood of further Regression Defects. Lack of cohesion also influences understandability and implies classes should probably be split into two or more subclasses.
  15. LCOM3 - varies between 0 and 2. Values 1..2 are considered alarming. In a normal class whose methods access the class's own variables, LCOM3 varies between 0 (high cohesion) and 1 (no cohesion). When LCOM3=0, each method accesses all variables. This indicates the highest possible cohesion. LCOM3=1 indicates extreme lack of cohesion. In this case, the class should be split. When there are variables that are not accessed by any of the class's methods, 1 < LCOM3 <= 2. This happens if the variables are dead or they are only accessed outside the class. Both cases represent a design flaw. The class is a candidate for rewriting as a module. Alternatively, the class variables should be encapsulated with accessor methods or properties. There may also be some dead variables to remove. If there are no more than one method in a class, LCOM3 is undefined. If there are no variables in a class, LCOM3 is undefined. An undefined LCOM3 is displayed as zero [1]. LCOM3 is calculated as follows: LCOM3 = (m - sum(mA)/a) / (m-1) where: m is number of procedures (methods) in class, a is number of variables (attributes) in class and contains all variables whether shared (static) or not, mA is number of methods that access a variable (attribute), sum(mA) is the sum of mA over attributes of a class.
  16. LCAM - Lack of Cohesion Among Methods (also referred to as "1-CAM")... CAM metric is the measure of cohesion based on parameter types of methods.
  17. NOF - Number of Fields (properties/attributes) in a class.
  18. NOM - Number of Methods in a class.
  19. NOSF - Number of Static Fields in a class.
  20. NOSM - Number of Static Methods in a class.
  21. SI - Specialization Index is defined as NORM # DIT / NOM... the Specialization Index metric measures the extent to which subclasses override their ancestors classes. This index is the ratio between the number of overridden methods and total number of methods in a Class, weighted by the depth of inheritance for this class. Lorenz and Kidd precise : Methods that invoke the superclass’ method or override template are not included.
  22. CM-LOC - Class-Methods Lines of Code is the total number of all nonempty, non-commented lines of methods inside a class.
  23. NoI - Number of Interfaces is the total number of Interfaces.
  24. NoCls - Number of Classes is the total number of classes in this project or specific module/package being examined.
  25. NoE - Number of Entities is the total number of Interfaces and classes.
  26. NORM - Number of Overridden Methods is the number of Overridden Methods.
  27. C3 - The max value of Coupling, Cohesion, Complexity metrics.
  28. nofP - Number of Packages in the project.
  29. nofPa - Number of External Packages is the number of External Packages referenced by the project.
  30. nofEE - Number of External Entities is the number of External classes and interfaces referenced by the project.
  31. NoPC - Number of Problematic Classes is the number of classes with high coupling, high complexity or low cohesion in the project.
  32. NoHPC - Number of Highly Problematic Classes is the number of classes with high coupling, high complexity and low cohesion in the project.
  33. LTCC - Lack of Tight Class Cohesion tric measures the lack cohesion between the public methods of a class. That is the relative number of directly connected public methods in the class. Classes having a high lack of cohesion indicate errors in the design.
  34. ATFD - Access to Foreign Data is the number of classes whose attributes are directly or indirectly reachable from the investiggated class. Classes with a high ATFD value rely strongly on data of other classes and that can be the sign of the God Class.
  35. I - Instability metric is used to measure the relative susceptibility of class to changes. It is defined as the ration of outgoing dependencies to all package dependencies and it accepts value from 0 to 1, and is calculated as follows: Instability = EC / (EC+AC) where: EC is Efferent Coupling measures "Outgoing Coupling" or the number of classes in other packages that the classes in the package depend upon is an indicator of the package's dependence on externalities, and, AC is Afferent Coupling measures "Incoming Coupling" or the number of classes in other packages that depend upon classes within the package is an indicator of the package's responsibility.
  36. Abs - Abstractness metric is used to measure the degree of abstraction of the package. abstractness is defines as the number of abstract classes in the package to the number of all classes.
  37. ND - Normalized Distance metric is used to measure the balance between stability and abstractness and is calculated as: ND = |Abs + I - 1|
  38. InDegree - In-degree of corresponding graph vertex of the class.
  39. OutDegree - Out-degree of corresponding graph vertex of the class.
  40. Degree - Degree of corresponding graph vertex of the class.

[13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]


Code Ownership

[25] [26] [27] [28] [29] [30] [31] [32]

Collective

All of the codebase is owned by the entire Dev team, and responsibility for the quality is shared amongst all sub-teams and each of the team members equally. There are no leads in this model, everyone is considered to be at the same level for all changes.

Flexible

The codebase is divided up into modules or logically related sections with each assigned a respective owner/lead and potentially a secondary lead if deemed necessary; but developers are allowed to change modules owned by other people through the team's defined Code Review process.

Strict

Very defined & intentional strategy where codebase is broken up into very granular modules (classes, functions, files) and each module assigned to one developer to take the lead and a secondary (as much as possible the "secondary" should be from another team), other devs then only allowed to make changes to modules they own or by special request to someone else's module; without such a request the owner or backup lead must be the ones to make the change.


Design Principles

[33] [34]


DRY

SOLID

[35] [36] [37] [38] [39]

YAGNI

KISS

SoC

Modularization

Coupling

Coupling occurs between two classes A and B if:

   A has an attribute that refers to (is of type) B.
   A calls on services of an object B.
   A has a method that references B (via return type or parameter).
   A has a local variable which type is class B.
   A is a subclass of (or implements) class B.

Tight-Coupling

Tightly coupled systems tend to exhibit the following characteristics:

   A change in a class usually forces a ripple effect of changes in other classes.
   Require more effort and/or time due to the increased dependency.
   Might be harder to reuse a class because dependent classes must be included.


Loose-Coupling

Cohesion

Low Cohesion

High Cohesion

Design Patterns

[40] [41]


Creational Patterns

[42]

Singleton

[43] [44]

Abstraction

Also commonly known as "Abstract Factory" pattern.

Factory Methods

Builder

Object Pool

Prototype

Service Locator

Often combined with Factory pattern to implement a layer of interfaces between Server and Client.

[45]


Structural Patterns

Adapter

[46]

Bridge

Composite

Decorator

Facade

Flyweight

Proxy

Behavioral Patterns

Observer


Chain of Responsibility

Command

Iterator

Mediator

Memento

State

Strategy

Template Method

Visitor

Architectures

MVC

Model View Controller (commonly abbreviated MVC) is one of the most prevalent architectural approach for building complex UI-centric applications on the web, mobile or desktop. It evolved from a number of advances in computer science but is particularly attributed to Tygve Reenskaug

[47] [48] [49] [50] [51] [52] [53]

MVVM

MVP



Approaches

No Code

[54] [55] [56] [57]

Low Code

[58] [59] [60] [61] [62]


Cowboy Coding

Every man, woman and child for themselves mindset programming, reminiscent of the Wild West. Development done in a silo, using whatever tools, languages or technologies one prefers, with little to no consideration to team/dept/organizational fit, maintainability, or broader long-term business value. Usually no documentation or coding standards.


Rapid Prototyping

Chaos Coding

Anti-pattern to quality/productivity.


RDD

Requirements Driven Design, typically paired with Waterfall, depends on analysts to deliver complete, detailed requirements to programmers for implementation with little to no collaboration before this hand-off. Requirements must be vetted for business value before reaching developers.

DDD

Design Driven, all functionality, look & feel details provided up-front, just turn an existing diagram/drawing/wireframe/storyboard into something that works in real life as described.


Pseudo-Coding

TDD

BDD


Pair-Programming

Teaming up between two specific team members (typically developers, but could be a developer with a tester, or, a developer and designer) to collaborate on delivery of a specific Backlog item (Story, Task, Bug fix, Project, Feature, etc).

[63] [64] [65] [66] [67]

Mob Programming

Also known as "Boardroom Programming" or "mobbing". Can be an anti-pattern if not relegated to very specific problem-solving, and if not constituting a very small portion of total coding efforts/outputs. While the "go-to" shouldn't be mobbing for every single Backlog item or issue worked on, it should be a reliable technique to use particularly for new tasks where there is a higher than normal degree of uncertainty where a broad spectrum of ideas is likely to produce the best solution, and also the best cross-team knowledge sharing.

[68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88]

Interviews

[89]

[90] [91] [92]

[93] [94] [95] [96] [97] [98]

[99] [100] [101] [102] [103]

[105] [106] [107] [108] [109] [110]

[112] [113] [114]


Onboarding

[115]


Certifications


Tools

  • Emmet: https://emmet.io/ | DOWNLOAD (HTML/CSS shortcut tool for web developers... type a CSS selecter/regex and auto-generate HTML templates or vice-versa CSS rules for a template)
  • Bubble: https://bubble.is/ (info toolkit for data-driven apps/websites without code)

E-Learning

Top programming E-Learning resources/courses/services include:

[119] [120] [121] [122]


Resources

[127]

[128] [129] [130] [131] [132] [133]

[138] [139]

[140] [141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151] [152]


[153] [154] [155] [156] [157] [158] [159] [160] [161] [162]


Tutorials


External Links

[171]


References

  1. Object Design Checklist: https://mcsee.medium.com/object-design-checklist-47c63d351352
  2. wikipedia: Declarative programming
  3. The Complete Guide to Declarative Programming: https://www.capitalone.com/tech/cloud/declarative-programming-guide/
  4. Declarative programming -- When “what” is more important than “how”: https://www.ionos.com/digitalguide/websites/web-development/declarative-programming/
  5. CSS is a Declarative, Domain-Specific Programming Language: https://notlaura.com/css-is-a-programming-language/
  6. Object-Oriented CSS -- What, How, and Why: https://code.tutsplus.com/tutorials/object-oriented-css-what-how-and-why--net-6986 (technique to match a Declarative programming language like CSS to a more OO mindset)
  7. wikipedia: List of programming languages by category
  8. FP vs. OO List Processing: http://blog.cleancoder.com/uncle-bob/2018/12/17/FPvsOO-List-processing.html
  9. Functional Programming Patterns -- A Cookbook: https://medium.freecodecamp.org/functional-programming-patterns-cookbook-3a0dfe2d7e0a
  10. Object-Oriented Programming — The Trillion Dollar Disaster: https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7 (opinion piece heavily favoring "Functional Programming" paradigms/languages over OOP)
  11. wikipedia: Reactive programming
  12. The Reactive Principles: https://principles.reactive.foundation
  13. Architectural Quality Assessment with CodeMR: https://codemr.medium.com/architectural-quality-assessment-with-codemr-f15de87a8d56
  14. Supported Metric List by CodeMR: https://codemr.medium.com/supported-metric-list-by-codemr-a119c3cffc2d
  15. What is the fascination with code metrics?: https://stackoverflow.com/questions/195887/what-is-the-fascination-with-code-metrics
  16. What code metric(s) convince you that provided code is “crappy”?: https://stackoverflow.com/questions/187289/what-code-metrics-convince-you-that-provided-code-is-crappy
  17. Visual Studio - Code metrics values: https://docs.microsoft.com/en-us/visualstudio/code-quality/code-metrics-values?view=vs-2019
  18. How to Generate code metrics data (in Visual Studio): https://docs.microsoft.com/en-us/visualstudio/code-quality/how-to-generate-code-metrics-data?view=vs-2019
  19. Measure Your Code Using Code Metrics: https://www.c-sharpcorner.com/article/measure-your-code-using-code-metrics/
  20. A Survey of Metrics for UML Class Diagrams: http://www.jot.fm/issues/issue_2005_11/article1/
  21. Eclipse - Metrics plugin: http://metrics.sourceforge.net/
  22. How to Measure Code Quality - 7 Metrics Every Engineer Should Know: https://www.stepsize.com/blog/how-to-measure-code-quality-7-metrics-every-engineer-should-know
  23. We Can't Measure Programmer Productivity… or Can We?: http://java.dzone.com/articles/we-cant-measure-programmer
  24. Measuring Software Complexity - What Metrics to Use?: https://thevaluable.dev/complexity-metrics-software/
  25. Capitalism, Socialism, and Code Ownership: https://blog.scottlogic.com/2021/09/30/Collective-Code-Ownership.html
  26. Martin Fowler on Code Ownership types: https://martinfowler.com/bliki/CodeOwnership.html
  27. Martin Fowler - Shifting To Code Ownership: https://martinfowler.com/bliki/ShiftingToCodeOwnership.html
  28. Weak Code Ownership in detail: http://blog.jayfields.com/2015/02/experience-report-weak-code-ownership.html (our team started out using this approach)
  29. DZONE - Code Ownership – Who Should Own the Code?: https://dzone.com/articles/code-ownership-–-who-should
  30. Microsoft -- Don’t Touch My Code! - Examining the Effects of Ownership on Software Quality: https://www.microsoft.com/en-us/research/publication/dont-touch-my-code-examining-the-effects-of-ownership-on-software-quality/?from=http%3A%2F%2Fresearch.microsoft.com%2Fpubs%2F150498%2Fbird2011dtm.pdf
  31. Scaling Collective Code Ownership & Code Reviews at LinkedIn - Nikolai Avteniev: https://www.brighttalk.com/webcast/5742/333544
  32. Capitalism, Socialism, and Code Ownership: https://blog.scottlogic.com/2021/09/30/Collective-Code-Ownership.html
  33. The 7 Virtues of Good Software Design: https://dzone.com/articles/the-seven-virtues-of-a-good-design
  34. Software Architecture Cheat Sheet for Daily Usage: https://azeynalli1990.medium.com/software-architecture-cheat-sheet-for-daily-usage-9923922ea75b
  35. Design Principles and Design Patterns - by Rob "Uncle Bob" Martin (2000): https://fi.ort.edu.uy/innovaportal/file/2032/1/design_principles.pdf
  36. A Solid Guide to SOLID Principles: https://www.baeldung.com/solid-principles
  37. Why every element of SOLID is (according to this author) wrong: https://speakerdeck.com/tastapod/why-every-element-of-solid-is-wrong
  38. Solid Relevance: http://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html (Uncle Bob's response to Dan North's "Write Simple Code rather than following SOLID" talk)
  39. CUPID – the back story: https://dannorth.net/2021/03/16/cupid-the-back-story/ (a bold claim that ever principle of SOLID is wrong)
  40. DesignPatterns implemented in JAVA: https://github.com/gkatzioura/DesignPatterns
  41. In28Mins -- Design Patterns for Beginners with Java examples: https://dzone.com/articles/design-patterns-for-beginners-with-java-examples
  42. How to Build Creational Design Patterns: Singleton Pattern: https://dzone.com/articles/creational-design-patterns-singleton-pattern
  43. Introducing the Single Element Pattern: https://medium.freecodecamp.org/introducing-the-single-element-pattern-dfbd2c295c5d | SRC
  44. WRITING TESTABLE CODEPRESENTATIONS Singletons are Pathological Liars: http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
  45. Design Patterns Explained – Service Locator Pattern with Code Examples: https://stackify.com/service-locator-pattern/
  46. Usage of the Adapter pattern in Java: https://refactoring.guru/design-patterns/adapter/java/example#lang-features
  47. wikipedia: Trygve Reenskaug (researcher who coined the term "MVC")
  48. The original MVC reports Trygve Reenskaug Dept. of Informatics University of Oslo: https://www.duo.uio.no/bitstream/handle/10852/9621/Reenskaug-MVC.pdf?sequence=1
  49. The Model-View-Controller (MVC) -- Its Past and PresentTrygve Reenskaug, University of Oslo: https://folk.universitetetioslo.no/trygver/2003/javazone-jaoo/MVC_pattern.pdf | BACKUP
  50. MODELS - VIEWS - CONTROLLERS originakl 1979 whitepaper: https://folk.universitetetioslo.no/trygver/1979/mvc-2/1979-12-MVC.pdf
  51. Origins of Model View Controller: https://medium.com/@duncandevs/origins-of-model-view-controller-d685528857ce
  52. Do MVC like it’s 1979 (on iOS/Swift): https://medium.com/bumble-tech/do-mvc-like-its-1979-da62304f6568
  53. Trygve Reenskaug's MVC specification applied to a Java Swing GUI app: https://codereview.stackexchange.com/questions/163146/trygve-reenskaug-s-mvc-specification
  54. New to "No Code"? Start Here: https://kissflow.com/low-code/no-code/no-code-overview/
  55. Stripe’s first no-code product -- Payment Links: https://www.producthunt.com/newsletter/8463-stripe-s-first-no-code-product-payment-links
  56. Plasmic: https://www.plasmic.app (visual builder for your tech stack)
  57. AppSmith: https://www.appsmith.com (powerful open source framework to build internal tools)
  58. TechRepbulic -- REPORT - "Low-code" tech is the future for businesses and entrepreneurs: https://www.techrepublic.com/article/report-low-code-tech-is-the-future-for-businesses-and-entrepreneurs/
  59. Is "Low-code" the best “new” technology breakthrough: https://www.prolim.com/low-code-the-best-new-technology-breakthrough/
  60. 10 Best Low-Code Development Platforms in 2021: https://www.softwaretestinghelp.com/low-code-development-platforms/
  61. Introducing "Microsoft PowerFx" -- the low-code programming language for everyone: https://powerapps.microsoft.com/en-us/blog/introducing-microsoft-power-fx-the-low-code-programming-language-for-everyone/
  62. AppWrite: https://appwrite.io (Secure Open-Source Backend Server for Web, Mobile & Flutter Developers)
  63. Pair Programming and Why We Do It: https://dzone.com/articles/pair-programming-at-codacy-and-why-we-do-it-1
  64. Pair Programming (aka. Pairing): https://www.agilealliance.org/glossary/pairing
  65. What Is Pair Programming?: https://dzone.com/articles/what-is-pair-programming
  66. A look at what "Pair Programming" is and its advantages/challenges: https://dzone.com/articles/what-is-pair-programming-advantages-challenges-tut
  67. On Pair Programming: https://martinfowler.com/articles/on-pair-programming.html
  68. Teaching using Mob Programming: http://blog.code-cop.org/2014/09/teaching-using-mob-programming.html
  69. A Day of Mobbing: https://www.youtube.com/watch?v=p_pvslS4gEI
  70. "Mob Programming" Time Lapse: https://www.youtube.com/watch?v=Ev7uus12HRY
  71. A day of Mob Programming 2016: https://www.youtube.com/watch?v=dVqUcNKVbYg
  72. Mob Programming: https://www.infoq.com/presentations/mob-programming
  73. Woody Zuill on Mob Programming and No Estimates: https://www.infoq.com/interviews/zuill-mob-programming
  74. Agile Alliance -- Mob Programming – A Whole Team Approach (explained by Woody Zuill): https://www.agilealliance.org/resources/experience-reports/mob-programming-agile2014/
  75. GOTO 2017 conference -- Mob Programming - A Whole Team Approach (Woody Zuill): https://www.youtube.com/watch?v=SHOVVnRB4h0
  76. Mob programming and shared everything: https://blog.codecentric.de/en/2020/02/mob-programming-shared-everything/
  77. Team-oriented development: https://blog.codecentric.de/en/2020/04/team-oriented-development/
  78. How to Find the Right Collaborative Coding Tool for Remote Pair Programming: https://dzone.com/articles/the-right-collaborative-coding-tool-for-remote-pair-programming
  79. The Surprisingly Inclusive Benefits of Mob Programming: https://cucumber.io/blog/inclusive-benefits-of-mob-programming/
  80. Mob Programming - the Good, the Bad and the Great: https://underthehood.meltwater.com/blog/2016/06/01/mob-programming/
  81. Speed Up Your Scrum With Mob Programming : https://www.scrum.org/resources/blog/speed-your-scrum-mob-programming
  82. How Mob Programming Will Make You More Effective: https://hackernoon.com/how-mob-programming-will-make-you-more-effective-590a1b7e0418
  83. I did mob programming every day for 5 months -- here’s what I learnt: https://medium.com/comparethemarket/i-did-mob-programming-every-day-for-5-months-heres-what-i-learnt-b586fb8b67c
  84. Mob Programming – A Whole Team Approach: https://www.agilealliance.org/wp-content/uploads/2015/12/ExperienceReport.2014.Zuill_.pdf
  85. InfoQ -- Mob Programming overview (VIDEO): https://www.infoq.com/presentations/mob-programming
  86. Ping-Pong, Paired Programing (VIDEO): https://thoughtbot.com/upcase/videos/ping-pong-paired-programing
  87. The Secret to a Great Planning Process — Lessons from Airbnb and Eventbrite: https://review.firstround.com/the-secret-to-a-great-planning-process-lessons-from-airbnb-and-eventbrite
  88. Don’t do Code Review, try Mob instead: https://medium.com/verotel/dont-do-code-review-try-mob-instead-82149ef035df
  89. 7 Brain Tips for Software Developers: http://www.javacodegeeks.com/2014/12/7-brain-tips-for-software-developers.html
  90. The 7 Highest Paying Companies for Tech Workers in 2021: https://medium.com/@SomeTechGuru/the-top-7-paying-companies-for-tech-workers-in-2021-3b51dabf99b7
  91. Why Don’t Tech Companies Pay Their Engineers to Stay?: https://marker.medium.com/why-dont-tech-companies-pay-their-engineers-to-stay-b9c7e4b751e9
  92. The Argument for Location-Based Salaries Is Falling Apart: https://www.wired.co.uk/article/location-based-salary-discrepancy
  93. Cracking The Coding Interview - 12 Things You Need To Know: http://dotnet.dzone.com/articles/cracking-coding-interview-12
  94. Top 10 OOP Concepts Interview Questions: http://www.instanceofjava.com/2015/03/oops-concepts-interview-questions.html
  95. 10 Tricky Core-Java Interview Questions: http://javaconceptoftheday.com/tricky-core-java-interview-coding-questions/
  96. 7 Programmer Recruiting Mistakes: http://en.codeceo.com/7-programmer-recruiting-mistakes.html
  97. Resume Writing & Interviewing Skills: http://slideplayer.com/slide/5942078/
  98. Unifying the Technical Interview: https://aphyr.com/posts/354-unifying-the-technical-interview
  99. How to Prepare for Your DevOps Interview: https://dzone.com/articles/how-to-prepare-for-your-devops-interview
  100. Your DevOps Interview: https://itchronicles.com/devops/your-devops-interview/
  101. What’s Your Favorite DevOps Interview Question? 20 DevOps Pros Share Their Favorite Questions and How Developers Can Prepare: https://stackify.com/devops-interview-questions/
  102. DevOps interview questions: How to prepare: https://raygun.com/blog/devops-interview-questions/
  103. Top 8 DevOps Interview Preparation Tips: https://www.coachdevops.com/2019/07/tips-for-attending-devops-interviews.html
  104. Database of JAVA interview questions: http://javasearch.buggybread.com/InterviewQuestions/questionSearch.php
  105. Most Frequently Asked Java Interview Questions: https://blog.usejournal.com/most-frequently-java-interview-question-127e923f70d9
  106. Top 20 Java Interview Questions by Hiring Investment Banks: https://dzone.com/articles/top-20-java-interview-questions-with-answers
  107. Senior Developers are Getting Rejected for Jobs: https://glenmccallum.com/2019/05/14/senior-developers-rejected-jobs/
  108. The Best of Java Interview Questions: https://dzone.com/articles/interview-question-cluster
  109. 50+ Java Interview Questions for Programmers: https://dzone.com/articles/50-java-interview-questions-for-programmers
  110. How Would You Answer This? "Tell Me About A Wrong Decision You've Made."​: https://www.linkedin.com/pulse/how-would-you-answer-tell-me-wrong-decision-youve-made-adam-bryant/
  111. Cracking the (Frontend) Coding Interview: https://blog.usejournal.com/cracking-the-frontend-coding-interview-ec7d5b1e6755 (with old-school vanilla JS)
  112. Recruiting Software Developers – Coding Tests (are they needed, and how to prepare): https://henrikwarne.com/2021/04/19/recruiting-software-developers-coding-tests/
  113. My Salary Negotiation Strategy: https://alexewerlof.medium.com/my-salary-negotiation-strategy-4c67419ccbcd
  114. Microsoft doubles budget for employee salaries to address inflation, retain talent : https://nypost.com/2022/05/16/microsoft-doubles-budget-for-employee-salaries-to-address-inflation-retain-talent/
  115. Tips for Onboarding and Training Employees With Disabilities: https://www.accessibility.com/blog/tips-for-onboarding-and-training-employees-with-disabilities
  116. Codecademy, the free online coding school, raises another $30M led by Naspers: https://techcrunch.com/2016/07/12/codecademy-the-free-online-coding-school-raises-another-30m-led-by-naspers/
  117. GLOT - Selenium Python "Headless Chrome" Test example: https://glot.io/snippets/ew3ok1nh2g
  118. wikipedia: The Typing of the Dead
  119. Web Development Tools You Need to Know by the End of 2014: http://java.dzone.com/articles/web-development-tools-you-need
  120. Top 20 Developer Tools of 2016: http://dzone.com/articles/top-20-developer-tools-of-2016-1
  121. 17 key dev tools for 2017: http://dzone.com/articles/top-17-tools-used-in-software-development
  122. Get your kids coding with Minecraft: https://developer.atlassian.com/blog/2016/02/get-your-kids-coding-with-minecraft/ | EXAMPLE
  123. Which programming languages are most popular (and what does that even mean)?: http://www.zdnet.com/article/which-programming-languages-are-most-popular-and-what-does-that-even-mean/
  124. PYPL PopularitY of Programming Language: http://pypl.github.io/PYPL.html
  125. The 9 Most In-Demand Programming Languages of 2016: http://www.codingdojo.com/blog/9-most-in-demand-programming-languages-of-2016/
  126. How Popular is JavaScript in 2019?: https://medium.com/javascript-scene/how-popular-is-javascript-in-2019-823712f7c4b1
  127. Sorting Algorithms visualized: https://www.reddit.com/r/educationalgifs/comments/5fcfe4/sorting_algorithms_visualized/
  128. Biased Algorithms Learn From Biased Data - 3 Kinds Biases Found In AI Datasets: https://www.forbes.com/sites/cognitiveworld/2020/02/07/biased-algorithms/
  129. Algorithmic Bias - Why Bother?: https://cmr.berkeley.edu/2020/11/algorithmic-bias/
  130. Bias In AI Algorithms: https://towardsdatascience.com/how-are-algorithms-biased-8449406aaa83
  131. Babysitting Racist Algorithms: https://www.mediapost.com/publications/article/364336/babysitting-racist-algorithms.html
  132. Google ‘fixed’ its racist algorithm by removing gorillas from its image-labeling tech: https://www.theverge.com/2018/1/12/16882408/google-racist-gorillas-photo-recognition-algorithm-ai
  133. Google Searching For New Skin Tone Measures To Reduce Bias: https://www.mediapost.com/publications/article/364335/google-searching-for-new-skin-tone-measures-to-red.html
  134. Design patterns, the big picture, Part 1 -- Design pattern history and classification (Part 1 of 3): http://www.javaworld.com/article/2078665/core-java/design-patterns--the-big-picture--part-1--design-pattern-history-and-classification.html
  135. Design patterns, the big picture, Part 2 -- Gang-of-four classics revisited: http://www.javaworld.com/article/2078675/core-java/design-patterns--the-big-picture--part-2--gang-of-four-classics-revisited.html
  136. Design patterns, the big picture, Part 3 -- Beyond software design patterns: http://www.javaworld.com/article/2071208/core-java/design-patterns--the-big-picture--part-3--beyond-software-design-patterns.html
  137. A Software Developer’s Guide to Side Projects: https://dzone.com/articles/a-software-developers-guide-to-side-projects
  138. Learn to Code with Star Wars: https://code.org/starwars
  139. Minecraft Hour of Code Tutorials https://code.org/minecraft
  140. Martin Fowler -- Strangler Fig applications to software refactoring: https://martinfowler.com/bliki/StranglerFigApplication.html (original post on the concept)
  141. Strangler Applications (examples/case-studies): https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/
  142. Monolith to Microservices Using the Strangler Pattern: https://dzone.com/articles/monolith-to-microservices-using-the-strangler-patt
  143. What is the Strangler Fig Pattern and How it Helps Manage Legacy Code: https://www.freecodecamp.org/news/what-is-the-strangler-pattern-in-software-development/
  144. Sharing UI Components to Build Consistent UIs Faster: https://medium.com/javascript-in-plain-english/sharing-ui-components-to-build-consistent-uis-faster-5e60141ca855
  145. Switching from LESS to SASS with the Strangler Pattern: https://hoyer.io/LESS-to-SASS-with-Strangler-Pattern/
  146. Strangler Applications: https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/
  147. Chopping the monolith: https://blog.frankel.ch/chopping-monolith/
  148. The Strangler Pattern in Practice: https://medium.com/homeaway-tech-blog/the-strangler-pattern-in-practice-96ff4ee117ca
  149. The pros & cons of the Strangler architecture pattern: https://www.redhat.com/architect/pros-and-cons-strangler-architecture-pattern
  150. Microservice Strangler Pattern: https://www.c-sharpcorner.com/article/microservice-strangler-pattern/
  151. What is the strangler pattern and how does it work?: https://www.techtarget.com/searchapparchitecture/tip/A-detailed-intro-to-the-strangler-pattern
  152. Strangler Fig pattern: https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler-fig
  153. Naming Conventions From Uncle Bob's Clean Code Philosophy: https://dzone.com/articles/naming-conventions-from-uncle-bobs-clean-code-phil
  154. 5 Tips to Master the Art of Clean Code: https://mrshrestha.medium.com/5-tips-to-master-the-art-of-clean-code-cdd11a25b372
  155. What Is Clean Code?: https://medium.com/s/story/reflections-on-clean-code-8c9b683277ca
  156. How to make your code better with intention-revealing function names: https://medium.freecodecamp.org/how-to-make-your-code-better-with-intention-revealing-function-names-6c8b5271693e
  157. Why 4 spaces are used as the unit of indentation in Java?: https://stackoverflow.com/questions/4802381/why-4-spaces-are-used-as-the-unit-of-indentation-in-java
  158. Why are spaces preferred over tabs as indentation in Python?: https://www.reddit.com/r/learnpython/comments/34dpn4/why_are_spaces_preferred_over_tabs_as_indentation/
  159. Domain-Oriented Observability: https://martinfowler.com/articles/domain-oriented-observability.html
  160. The Clean Code Talks - Don't Look For Things!: https://www.youtube.com/watch?v=RlfLCWKxHJ0
  161. 10 Must-Have React Developer Tools to Write Clean Code: https://dev.to/alexomeyer/10-must-have-react-developer-tools-to-write-clean-code-1808
  162. Every second matters - the hidden costs of unoptimized "Developer workflows": https://humanitec.com/blog/hidden-costs-of-unoptimized-developer-workflows (excellent chart of max. time to spend to save a certain amount of time, based on frequency of the task carried out)
  163. The Well-Grounded Java Developer: http://manning.com/evans/
  164. Eclipse Collections Kata: https://github.com/eclipse/eclipse-collections-kata
  165. JVM Calendar -- 19 Lessons in a Kata: https://dzone.com/articles/jvm-calendar-19-lessons-in-a-kata
  166. Code Kata: http://codekata.com/
  167. Elvis operator etymology: https://stackoverflow.com/questions/35844113/elvis-operator-etymology
  168. Tabs vs Spaces -- How They Write Java at Google, Twitter, Mozilla and Pied Piper: https://blog.takipi.com/tabs-vs-spaces-how-they-write-java-in-google-twitter-mozilla-and-pied-piper/
  169. * Linus Torvalds on 80-character code limit being outdated, suggests 142: https://lkml.org/lkml/2020/5/29/1038
  170. Refactoring comics/infographics: http://llewellynfalco.blogspot.com/p/infographics.html
  171. Leak of Microsoft Salaries Shows Fight for Higher Compensation: https://onezero.medium.com/leak-of-microsoft-salaries-shows-fight-for-higher-compensation-3010c589b41e
  172. Changelog podcast #463 - 10,000 hours concept applied to development: https://changelog.com/podcast/463

See Also

Programming Languages | IDE | E-Learning | Technology/TechDebt | Virtualization | Docker | OS | Device | Client/Server | API | Testing | CI/CD/CDD | DevOps | Agile | PM | Productivity | LAMP | MEAN | WebApp | DesktopApp | Mobile App