Is Intellectual Property Endangered By Remote Developers In Startups?

Successful open source businesses depend on factors outside of their codebase, such as:

  • Brand positioning and PR
  • Customer base
  • Portfolio
  • Talented engineers and business professionals able to scale
  • Strategic partnerships
  • Investments

If Facebook’s codebase gets stolen and replicated as NewFacebook.com, who cares?

Even Technological Companies Don’t Revolve Entirely Around Their Codebase

Sure, high-quality product is a necessity for acquiring market share. But there’s so much more to that.

  • Will you beat Google’s market share and adoption if you clone their codebase to a new domain?
  • Can you take over Airbnb without their reputation, customer base, and listings?
  • How would you recruit drivers and riders if you clone Uber’s or Lyft’s apps on the AppStore or Google Play?

Successful businesses build a name, acquire market share, land investments, hire A-star players, and keep dominating by innovating quickly. Chances are, a single developer stealing the entire codebase (virtually impossible) will be light years behind the original product a couple of weeks later after all the work put in by the core team.

There’s A Negligible Concern Over Stealing A Codebase

Moreover, companies have strict contracts in place (and hungry legal teams), patents, and investments that could keep them afloat for much longer. A single rogue developer cannot overtake an entire market with a leaked source repository.

How To Gain Experience As A Junior Developer

Let’s review that from an employer’s perspective.

Software Engineering Experience

The First Week Or Two

Someone with no practical skills and proven experience joins your team. You greet them, show them around, introduce them to the team, let them settle on their desk.

You share the access to your VPN, add them on Dropbox or Drive, give them the documentation of the first project they will work on. Organize a brief meeting with the other devs if you want to – that’s fine.

You let them install their technical stack and expect them to start triaging bugs and issues over the first days – and hopefully take it from there.

This will fail miserably.

What the Fresh Developer (Most Likely) Lacks

  • Technical skills.
  • Knowledge of the best technical stack they need to use (or whatever the company uses).
  • Experience with GitHub/Bitbucket, continuous integration, deployment scripts, unit testing.
  • No exposure to a large (or even an existing) project.
  • Lack of familiarity with the concepts of a large product – architecture, infrastructure, foundations.
  • No practical experience refining software with backward compatibility in mind.
  • Limited experience in testing the problem in numerous ways, knowing what may fail on the technical end (edge cases or regressions).

What will likely happen is lack of progress whatsoever or a number of hot patches that break pretty much everything.

Then come the communication and management skills.

I’m not talking about “leading a team”, of course.

But while working on bugs (or even during the documentation review), a developer is about to:

  • Estimate certain features or prioritize the backlog.
  • Ask specific questions clarifying the business’s needs and the context of the assignment.
  • Build a mental model of the problem in their head.
  • Prepare a patch that complies with the rest of the code base (coding standards, expected code coverage).
  • Adequately reassign the task with an appropriate comment explaining the fix and documenting it.
  • Documenting the behavior elsewhere – in an actual documentation or a PM backlog repository.
  • Look for existing approaches leading to reusability of code and effectively applying existing strategies for solving a known problem.

Here comes the problem with unexpected behaviors, unclear assignments, and inefficient communication.

Why Juniors Require Proactive Mentorship

The thing is, the freshman lacks technical skills, computer science background (in practice), actual expertise in working on existing projects, communication chops, teamwork skills and other things described above.

That ends up in a large set of activities that should be worked upon simultaneously. Each one may take months until you get a productive person on board.

Some get up to speed faster, others don’t. A company may invest over a year in onboarding and training until they get any reasonable results on fairly trivial tasks.

Add a year’s worth of salary to the equation.

And then add the weekly time of all team members involved in the mentorship process. The mentor should handle three things:

  • Do their own full-time job.
  • Help, coach, educate, mentor, support the beginner.
  • Fix the mess after that which wasn’t assigned to them in the first place.

Many of my friends hiring their first junior employee as tech founders say that they work 2 shifts since it takes twice as long to handle your workload and a new person (and their work).

Juniors may look around fairly soon.

Software Engineers Tenure Versus Company Size

HackerLife shared a research[1] discussing the average tenure of software engineers in San Francisco:

Software Engineer Tenure
A screengrab from https://hackerlife.co/blog/san-francisco-large-corporation-employee-tenure

It’s not unlikely to spend 3–5 years or more in the leading companies worldwide. But that usually applies to experienced senior engineers looking for a solid full-time job which lets them do what they love while taking care of their life (family, friends, travels).

This explains the tenure in small companies (1.5 years) – combined with the lack of other perks and often a lower salary (or a bonus package).

But if you’re a small or a mid-sized company, training a junior for a year with them leaving in a few months, how would that reflect on the business, the team morale, their ongoing progress?

Hiring a junior developer requires a leap of faith. What helps is experience in internships, working on pet projects, collaborating with other developers on side gigs, joining an open source community and other indications that the developer has spent the time and effort which would reduce the learning curve and increase the odds of an effective partnership for a longer period of time.

Footnotes

[1] Software Engineers Tenure in San Francisco

On Working As a Developer Only For a Paycheck

Why is it that when it comes to computer programming, everyone completely warns against doing it for the money?

What Is Software Engineering Anyway?

Software development has been continuously hyped, praised, promoted by media for various reasons – high salaries and increasing demand being the primary ones. Some of the most valued companies out there are in the tech field as well. Some of the richest people in the world happen to come from a programming background, too.

It also tends to be more accessible in terms of remote working opportunities, lack of degree requirements, freelance opportunities, and lucrative job perks.

Peaking Interest In Computer Programming

This is exactly why the percentage of people enrolling in programming courses and switching to the IT field is drastically higher than any other field out there. Despite the fact that legal jobs, marketing gigs, medical professions, financial opportunities may very well be just as well paid (if not better).

Now imagine yourself being a passionate developer in a team of 10 geeks. Your hiring manager schedules 50 interviews looking for 5 new recruits. And you end up with 5 fresh colleagues who couldn’t care less about the craft and shake the entire work culture at the office.

On top of that, you tend to organize meetups with your colleagues, attend 3–4 technical conferences every year, share tutorials and industry news on Slack. You see the disconnect between your tech circle and the new hires.

Geek-Driven Organizations

It could be demoralizing and is one of the main reasons why people are so attracted to companies like Google, Netflix, and Facebook, known for their internal tech communities.

The software development field is evergrowing. New frameworks, libraries, technologies, software updates and tools pop up all the freaking time. It evolves much more rapidly than most fields out there.

A professional developer is most likely going to spend a good chunk of their time studying and conducting R&D. It’s not the type of job that you can study at the university, spend 2–3 years mastering and do for the rest of your life. Without intrinsic motivation and actual joy in building software applications, you’ll end up being stressed out, dissatisfied, and pressured by the job requirements.

Of Course, Money Matters

Yes, a lot of software developers are highly motivated by the salary. But, that does not mean that they do it solely for the paycheck. They may be ambivalent or generally chill about doing their day-to-day, but that doesn’t mean they don’t care about their craft.

Software development would still be in the top 5 (or top 3) of the jobs they would pick with their skill set if the pay was equal.

It would still be a viable alternative – even if it’s not their number one life goal.

But diving into software development with zero motivation and only for the paycheck? That’s a recipe for disaster in the long run.

Programming Languages Used By Large Companies – PHP vs. Java

Some people try to bash PHP and explain how building high-scale platforms work.

Since that’s a bit biased, I’ll try to outline a different perspective – as a certified Java programmer who currently runs an agency with PHP developers.

In terms of “website developers”, there is no clear statistics since a good chunk of developers don’t engage in surveys and don’t necessarily follow industry blogs and magazines running those.

Based on two different attempts to gather that number back in 2012–2013:

Oracle says it’s 9,000,000. Wikipedia claims it’s 10,000,000. And the guys from Numbers Archives – A Knowledge Archive seem to be the most precise – they know that there are exactly 9,007,346 Java developers out there.

This was gathered from Plumbr.

With more than 5 million PHP programmers active globally, the demand for PHP remains strong and is on track for further growth. This is second only to Java, the most popular platform for the enterprise, which currently has about 9 million developers worldwide.

That’s straight out of Zend’s report and conveniently mentions Java as well.

Now, it’s worth noting that Java is a multipurpose programming language that leads the development of Android applications (and J2ME apps back in the day), could be used for desktop applications, server development, web services, embedded development, and whatnot.

Web Developers

So it’s not unlikely that the number of Java and PHP web developers is approximately the same.

If you browse for additional statistics, you’ll find that PHP is used by 83.1% of all the websites whose server-side programming language we know.

But it’s also important to understand that the majority of the web is comprised of blogs, small business websites, hobbyist magazines and other non-crucial pet projects.

A good exercise to understand the landscape is reading Programming languages used in most popular websites – Wikipedia which outlines what full-time developers use in some of the top websites out there.

Programming Languages Used By Large Companies - PHP vs. Java
A Screengrab from Wikipedia

You will see that Java is widely used by Google, YouTube, Amazon, Twitter and many more. But among the most visited websites, you will find Facebook, Yahoo, Wikipedia and WordPress.com that rely on PHP.

Java Is Preferred By Enterprises

Engineers may argue a lot about which one is better despite the numbers. Java is generally preferred by enterprises and large corporations – although you can find a number of other programming languages used by others.

But Java is clearly an overkill for small projects.

When I switched to PHP, I had spent 8 months building a CMS on top of JavaServer Faces and I wanted to use it for freelancing and ongoing development.

Why I Gave Up Two Weeks Later?

PHP vs. Java

  • Java is generally heavier and slower than PHP for smaller projects (consumes more resources and allocates a ton of stuff while bootstrapping a simple app).
  • Almost all hosting vendors back then supported PHP and just a handful did that for Java. Java hosting plans were generally 4–6 times more expensive (for seemingly the same expected output).
  • Many simple applications required a blog, a gallery, a forum connected to their website back then. There was WordPress (before becoming a CMS), Gallery2, phpBB/vBulletin that people knew very well and ran on PHP.
  • Finding freelance jobs for PHP was significantly easier (for me) than Java. Most companies looking for Java developers were only hiring full-time people or contractors for 6–9 month projects (due to the specifics and volume of a traditional Java application).
  • Since Java is more verbose, plenty of simple activities required setting up XML configuration files, additional classes for Hibernate connections or sifting through complex components dynamically generating AJAX callbacks or simple dropdown menus. Sure, there are workarounds – but it was definitely taking significantly longer for simple activities.

This is essentially how I switched to PHP when I became a full-time freelancer and kept training technical courses in Java. Demand was different depending on the niche/industry and opportunities were different as well.

Both programming languages used often are great in certain areas. But quantifying numbers and generalizing is counterproductive – hence my attempt to showcase some specific stats and use cases.

Most Common Pitfall That Lean Engineering Teams Run Into While Building At Scale

Lean Engineering TeamsPoor Planning And Weak Processes

The lean engineering process is agile and fast-paced, with numerous moving wheels in any single moment. Usually, the technical architecture is in place – the steps have been laid out, sprints are in place, continuous development is the way to go.

But What Happens When Something Goes South?

Short iterations and continuous improvements aren’t easier to match and gauge. Initial analysis is usually trimmed down, since it’s a recurring activity performed every week or two. So, fewer people estimating tasks, less attention in terms of risk management, simple goals to be achieved.

The standard problems which occur with lean engineering teams are:

  • Miscalculated estimates
  • Buggy features not caught by automated tests or manual QA (due to time constraints)
  • Undocumented changes adding up over time
  • Miscommunication from tech folks failing to deliver and/or report a problem
  • Future sprints not accounting for delayed or buggy features
  • Inadequate management of technical debt
  • Missing project revisions (every 2–3 months) calibrating the pace and the ongoing goals

For instance, a social network starts small, grows in popularity, keeps pushing changes, and follows their initial process zealously. In the meantime:

  1. The project grows in scope – several high-scale features are added to the pipeline over the next few months.
  2. Dozens of team members join the team. Onboarding may be insufficient, thus experienced folks are pulled frequently for guidance, mentoring, code reviews, business revisions.
  3. Bug reports and customer requests keep piling up. Prioritizing becomes a challenge.
  4. Major bugs keep interfering with the sprints, delaying other features.
  5. Testing takes longer. Bugs and new features pushed together, regressing existing functionality.
  6. Performance is challenged. Speed optimization sprints are planned, in addition to bug fixes and business requirements on the roadmap.
  7. Technical debt gets pushed back over and over, along with documenting change sets and keeping everyone up to speed.
  8. Companies often hire scrum masters or other senior managers with different styles of work who try to get everything back on track, often taking a long period of time to rectify anything, stressing everyone out and digging deeper and deeper.

It’s A Fine Line

It’s a fine line balancing bug fixes, new features, performance and security updates, scalability, additional business requirements by partners and investors, code cleanup, and keeping everyone in sync.

Depending on the growth curve, this may happen pretty much out of nowhere, leaving the business with scarce resources, sometimes turnover due to stress, roadmap out of sync, and bugs lurking under the surface.

Service-based companies are most prone to facing this earthquake and failing to get on track without losing several high-profile projects. There are too many stakeholders with arbitrary deadlines and requirements, leading to communication overhead and challenging team scale in-house across different teams.

Of course, this is just as applicable for product companies, reporting to a board of directors, investors, partners, and the public (especially in the event of bad PR).

Senior Management Having An Outline Of The Process

Best-case scenario, senior management would outline the process a couple of years ahead, based on statistics and projected growth and interferences. A sample plan can cover:

  • Sprints allocated on performance optimization and cleaning technical debt – probably every 4 months at first, 2–3 months a year after.
  • More wiggle room in every sprint – such as booking resources at 70%, preventing layoffs, holidays, sick leaves; planning for onboarding, meeting sessions, and more.
  • Carefully planning less important features in the roadmap. Here’s why…
  • Scope review every 3 months or so. Pushing back on less critical features if needed, or celebrating deliveries of “bonus” assignments if everything moves as anticipated (best-case scenario). Making sure documentation and onboarding docs are kept up to date – and quickly updated in case they aren’t.
  • Proactive communication at all times. Reporting a problem, scope creep, miscalculated estimates ASAP can prevent multiple bottlenecks from piling up later on.
  • Preparation for rainy days. Covering possible PR obstacles, competition intervening, lack of talent delaying projected growth, budget management.
  • Willingness to turn the process around if and as needed. Flexibility to act outside of the established protocol as soon as it’s clear that the current workflow won’t accommodate the ongoing roadmap.

While being inconclusive, the plan sets some extra buffers and allows for hiring early on, automating critical tasks and projects, allocating enough time for reviews and everything in-between.

Single Greatest Advice For A Young Engineer Entrepreneur

It’s not all about programming.

I’ve seen hundreds and hundreds of technical folks starting businesses with no clue how to run an organization, build a team, manage finances, build UX-driven interfaces, or close a deal.

Literally.

There’s a certain level of elitism within the software development industry. I’ve been there myself and it’s absolutely transparent whenever you attend a technical conference or join a geek online community and observe a few conversations.

It’s not necessarily a bad thing. It’s often instrumental in ongoing professional development and solving critical problems at work. And most experienced programmers are very well aware of the fact that programming isn’t everything.

I’ve been doing training courses since 2006 and worked with thousands of junior developers. Most of them are genuinely in awe of the software engineering industry which is vast and unexplainable at first. There’s a lot to learn and explore over the years.

Great entrepreneurs with a technical background are fully aware of their skill set and their weaknesses. Many spend years to catch up on different industries and improve their professional qualifications accordingly – even if they have business co-founders and after establishing a team of industry experts.

For example, a web application for a business may be a mission-critical component. However:
  1. That web app should present the back-end data in the fastest and most efficient manner through the front-end layout.
  2. Which is built atop the original design created by a graphic/web designer.
  3. Which has been coordinated with the branding team and UX experts confirming the corporate identity.
  4. That same application may utilize more complex queries and stored procedures requiring data scientists or DBAs.
  5. All of that grows and requires a team of network engineers, system administrators, or DevOps experts.
  6. All of those platform and service costs – along with salaries – are to be broken down and managed by the accounting department handling taxes and transactions as well.
  7. And if they are sick, someone may need to handle the recruitment process or deal with the sick/vacation holiday leaves within the HR team.
  8. Progressing at the right pace through the milestones is contingent on solid leadership roles and project managers.
  9. Project managers have landed the deal/funding (in the first place) thanks to the sales or business development department working along the legal team.
  10. The deal was sealed after your business has continuously appeared in multiple online and offline mediums thanks to the effort of the marketing department.

Basically, there would be no need of the web platform without the efforts of a team specializing in plenty of different fields. The application is merely a solution – or the best possible implementation – of a problem that has been discovered, broken down into the atomic details, defined with a business need in mind, and presold to customers paying the salaries.

Since startups cannot afford to hire dozens of rockstars, profiling in each niche, great entrepreneurs hustle and cover many of those areas themselves over the first months or even 1–2 years.

Sticking to your software engineering skill set is important for your professional qualification as a developer. However, entrepreneurship requires a ton of different skills – and the more you’re comfortable with doing yourself during the first year, the easier it will be to scale, save resources, make smart decisions and grow the business until you can hire more experienced folks.

Handling Refused Feature Requests

Estimates are incredibly challenging for innovative service development. The context of each application is different – the vendor will likely use different frameworks combined with various libraries and 3rd party services in each project.

The only reasonable way to provide a good estimate is based on former experience. If you’ve implemented the exact same thing several times within the exact context, an estimate is feasible. Otherwise, scope creep and additional business requirementswill inevitably get in the way.

This is the reason why only a fourth (if not less) of all fixed-fee projects get delivered on time and within budget. That’s why the software industry is slowly moving to agile development instead.

Otherwise, your estimate will almost never be accurate.

Regarding the ability to deliver something…

There are very few things that are not possible within the realms of software development. The only difference is time for execution and required resources.

Whenever a vendor says “We can’t do that”, it means one of these few things:

  • We don’t have the skills/don’t know how to build that.
  • We are not willing to research and investigate the possible options for delivering that.
  • It seems complicated and we won’t be able to estimate it for you.
  • Knowing your budget, we’re certain that it won’t be something that you can afford.
  • Given the deadline, there’s no way we can deliver that on time.
  • It’s going to be extremely complicated and depend on various different things. It will have known limitations upfront that won’t follow the exact same initial requirements.

By far, the last excuse is the most controversial one. And that’s a common case when vendors simply say that a feature is impossible instead of explaining the context.

The solution may not be supported by certain browsers or servers. Or there may be impact on performance or security. Or a certain approach would impact the user experience for certain applications.

Sometimes, the drastic difference in scope and requirements is unclear to a non-programmer:

For example, in this case the first solution would simply geolocate the phone and map it based on a limited set of coordinates for all national parks in the country.

The second solution requires machine learning and image recognition, a team of experts and a large database for existing birds and similar objects in order to get the highest success rate possible from a machine.

Occasionally, I have to discuss similar odd requirements with my clients. Instead of declining a request, I go on and explain the possible risks and limitations instead. It’s often expensive and out of scope and that’s fine – but at least they can give it a thought and decide how important it is while knowing what the actual challenges are.

I’ve also joked with some of them by saying, “I don’t know how to build a rocket and launch it into space – but give me $50B and 25 years and I’ll figure it out by then”. Elon has done it and Falcon 9 costed under a billion last time I checked, so there IS a way – despite being insanely expensive and time-consuming.

If you are concerned about estimates, hire a CTO or a technical consultant who can double check the requirements and validate the estimates. Or work with a predefined budget and ask whether something is feasible, or not.

Regarding the ability to accomplish something – always ask repetitively until you get the main reason for the problem. If it’s expensive or complex, that’s fine. Otherwise, if the team is simply not willing to help out, you may look for other vendors who are more proficient or willing to do the R&D for you.

 

 

3 Mistakes New Developers Make

Communication

Instinctively, communication pops up first. But I also realize how challenging it is for new developers in the workplace.

We have a girl who completed our internship training and was offered an entry-level role. She’s assigned to a new “manager” (our front-end lead) and we’re always proactively asking for updates and offering help because:

  • She’s younger and still not used to communication 101, plus the generation gap
  • She has no work experience to date
  • Lack of “team work” experience as well, she’s self-taught through MOOCs
  • Her mentor was someone else (not her current manager)
  • She’s practically freaked out by the vast volume of information to go through

So while communication is her only way out, there are valid reasons why she’s feeling so uncomfortable and additional help should be explicitly offered on a regular basis.

Not Learning From Mistakes

But the thing I really, really can’t stand is not learning from mistakes.

Most aspects of the job are tolerable. Juniors tend to learn new platforms (or languages), get acquainted with business processes, adapted in a new environment, get used to communication and adhering to processes and deadlines.

It’s a lot to tackle at once, and that’s fine.

What isn’t fine is ignoring or taking feedback lightly.

Can’t Grasp The Basics Of Programming

We’ve had some interns who can’t grasp the basics of programming. They can’t access a hashmap or a multi-dimensional array. We take the time to explain the basics of how data structures work and how to use them accordingly (despite being really basic).

A couple days later, another few hours spent on the same problem. A different method used to train the person on solving that error.

Early next week, back to the very same issue. Without indicating a problem or asking for help – just committing a basic bug fix throwing a warning due to improperly accessing an array index.

That’s not fine.

The other common case is escaping input or verifying variables. In dynamic and typeless programming languages, a variable could be anything — and placing a basic check upfront is more than mandatory. Failing to grasp that after repeating that 5 times ranks acts demotivating to the mentor or the corresponding colleague.

It’s perfectly fine if you don’t know a lot of stuff. But unless you pay close attention to what your team is trying to teach you, there won’t be any notable progress. Here’s where communication comes into play, too — ask follow-up questions and indicate problems early on and you’ll be good to go.

Machine Learning in 2018

Back when I was starting my professional programming career, I was really passionate about desktop applications.

I had some Visual Basic apps that I built by myself, studied Delphi at school, and worked as a Java developer. Since my first complex project was a distributed ERP for a large manufacturing organization, I really enjoyed building desktop software. Most of my pet projects at home were Swing apps, too.

The company I was working for transitioned to web development and my technical manager told me that “web is the future”. I thought he was either nuts, or wanted us to become front-end developers or something along those lines.

Nowadays, we watch video through Netflix, listen to music via Spotify, chat with Slack or the web version of Skype. The mobile wave struck as well, and then we saw the innovations in front-end development, the progress of IoT, and the demand for machine learning and different AI applications.

Machine Learning is definitely a thing now and various organizations look specifically for candidates with ML expertise.

  • Social networks rely heavily on more progressive algorithms for data curation and determining business expectations.
  • Banks vet credit applicants thanks to machine learning.
  • Games include different AI components for their automated bot applications.
  • Search engines dive deep into machine learning and personalized content.
  • Content management systems and eCommerce platforms benefit from custom tailored newsletters and relevant products based on the previous user behavior.

Many enterprises rely on statistical probability and automated mathematical models in order to define the relevant behavior for each customer accordingly.

In terms of career growth, former expertise in machine learning is definitely handy from a software development standpoint.

This skill set will probably be relevant for the next 5–10 years as well.

That said, the IT industry tends to automate and optimize processes – both for convenience, speed of execution, and by reducing the minimum requirements for hiring new staff members.

Maths was pretty much mandatory for software development back in the day. Then standard software libraries were introduced to most modern programming languages – handling search and sorting capabilities, among other optimized data structures and helpful algorithms.

Web development was a creative and complicated craft a while ago; and numerous service providers still rely on providing outstanding web development services for reputable organizations.

But that also brought millions of site builders installing WordPress with a few plugins for small and medium businesses. Wix, Squarespace, Weebly, Shopify attacked the market with self-hosted, DIY websites. Facebook Pages became a viable alternative for businesses that rely heavily on active Facebook users.

In time, Machine Learning will become automated to a certain point. Organizations will still need a percentage of professional developers with practical ML expertise. But frameworks and libraries like TensorFlow and Amazon Machine Learning will make it easier for less proficient developers to apply machine learning concepts into modern software applications.

All in all, studying machine learning is a smart career choice for software engineers. But those who aren’t ready to ride the first wave will still have simplified alternatives 5 years from now.

Related resources:

The Current State of Programming in 2017

Back in the day, being a software engineer wasn’t sexy. It was a deliberate choice by people who were obsessed about tinkering machines and the rising world of information technology.

Nowadays, we see active discussions from programmers such as As a programmer, do I have to absolutely love writing code? by people who are employed as developers and don’t even enjoy the craft anymore.

The European Commission has reported a realistic shortage of up to 900,000 skilled ICT workers by 2020 – Digital skills, jobs and the need to get more Europeans online – European Commission – European Commission

The high demand for software engineers leads to Computer Science and Informatics programs popping up across the world without the right planning or attitude by professors. A ton of people with no passion for programming choose the craft simply because it’s profitable and promising over the past 2–3 decades.

This leads to an entire generation of non-motivated people who simply program for a living, or practice job-hopping for a living in order to find a high-paid gig with numerous company benefits, bonuses, shares, remote working opportunities and the like, without enjoying programming at heart.

Of course, that’s not a rule of thumb – but it’s a growing trend. I am a seasoned teacher at several universities, academies, and schools, and a large percentage of my students have simply signed up thanks to the trend of working in the IT field, or the fuzz around the unicorn companies.

In terms of programming experience or background, I’m not a proponent of the traditional education but I know how important is the in-depth know-how of computer architectures, data structures, algorithms, networks, and a ton of other courses studied in Computer Science classes. Self-learning platforms like Codecademy, Code School, Udemy, Free Code Camp, Coursera, Pluralsight often focus on promoting how easy programming is and how quickly newbies can become professional programmers. It’s a standard marketing talk, but people really buy into it.

Sites like TechCrunch and Mashable constantly cover stories about massively successful entrepreneurs who sold their startups for $500,000,000 or so, or crafted something within a week that became an overnight success. It’s easy to read between the lines with a decade or two of experience in the field, but is often deceiving for beginner programmers who dream of building something for a week and becoming millionaires the very next day.

Start-up communities are flooded by fresh programmers who are aiming for The Next Big Thing. They have no real world experience programming for enterprises or high-scale solutions, nor do they have business experience that allow them to build MVPs that can scale iterationally as the product grows (or understand what are the limitations that are being pushed with the influx of traffic or user sign ups).

Professional Q&A networks like StackOverflow targeting programmers are invaded by beginner programmers with no experience asking for basic 101 questions available on the first page of Google with the right search term. Fresh programmers are often lazy, unwilling to spend the time to dig into documentation or conduct any sort of R&D before building something. There are fewer pet projects build by enthusiastic programmers who want to launch something and learn along the way as their project grows and requires more and more features and better scalability patterns.

At the end of the day, not all hope is gone, and there are millions of fresh college students or young programmers who are talented, smart, and willing to learn. But there is a large volume of people signing up for developers without the right attitude or understanding that programming is a craft that requires constant learning and continuous improvement, unlike some stalled professions that haven’t evolved over the past century.