Posted on No Comments on “Are developers paid only to write the code?”

“Are developers paid only to write the code?”

In my previous post Are developers like instrument players? I have posed a concluding question “Are developers paid only to write the code?”

Now I will go into lengthy details, joining discussion present on a couple of blogs.

 

Technical responsibilities

Let’s talk about responsibilities a developer can be asked to do beyond writing the code.

Build process

  • create and integrate build server
  • maintain a build server
  • prepare scripts to support the build process

Ideally, one of the engineers in a larger company is responsible for builds in all of the projects. For smaller companies, it is planned and someone familiar or willing to learn is recruited.
 

Environment issues
A developer, as a technical person, may often be asked to deal with his technical issue himself, like:

  • operating system issues
  • network issues
  • hardware issues
  • development environment maintenance
  • any needed software for development

Ideally, there would be an infrastructure engineer in the team or general IT support to help, even for “advanced users” like developers.
 

Documentation

  • technical documentation – developer created a specific solution and at least overall design or important notes should be captured
  • user documentation, feature presentation – developer built the features and he knows them best
  • installation documentation – software requires some manual steps or prerequisites, otherwise, it will not be possible to install it correctly

Ideally, a technical writer can create the documentation, while developers in the project will just review it.

 

Soft responsibilities

Knowledge sharing

  • help the newly joined programmer with the project or technology
  • prepare a technology presentation for the team
  • code review

Ideally, to avoid all of that, all of the non-coding can be performed by an experienced developer and now a team leader.
 

Cooperation

  • joining various meetings within the team, but also with 3rd parties or the client
  • reading technical and business documentation
  • understanding the business side of the project

Ideally, all of that would be done by a business analyst, system analyst, an architect, product owner, and a team leader.
 

Responsibility

  • ensure data input will be secured when your task says to code input data form
  • ask for a clarification when requirement may be missing
  • check if your change would break something else
  • make sure user would know how to use the feature
  • make sure your colleague is solving his current problem correctly in the same feature you are working with now

Ideally, the responsibility of everything working together is on the team leader, client accepting UAT, or PM.

 

The world is not ideal

Specialization
Even in big companies specialists only to write documentation or configure build servers are not present. Either company doesn’t feel the need, recruiting that kind of specialists is difficult, or there would be not enough work to do full time for each specialist.

Then the code-only siloed specialists are faced with non-coding tasks.

The problem of “siloing of responsibilities” has been touched in the famed article You Are Not Paid to Write Code by Tyler Treat:

Product, Platform, Infrastructure, Operations, DevOps, QA—whatever the silos, it’s created a sort of responsibility lethargy. “I’m paid to write software, not tests” or “I’m paid to write features, not deploy and monitor them.”

 

Comment made by DanielBMarkham on related discussion on Hacker News makes a good summary:

(…) A couple of years ago I was teaching tech practices to a team that was deploying on iOS, Droid, and the web. After we went over TDD, ATDD, and the CI/CD pipeline, I emphasized how crucial it was not to silo. When I finished, a young developer took me aside.

“You don’t understand. We have coders here who just want to do Java. They want to be the best Java programmers they possibly can be.”
I told him that he didn’t understand. Nobody gave a rat’s ass about people wanting to program Java. They cared about whether the team had both the people and technical skills to solve a problem they have.

It would be as if a carpenter refused to work on a cabinet because it wouldn’t involve using his favorite hammer. You’re focusing on the wrong thing.
Sadly, once you get this, the industry is all too happy to punish you for it. That’s because the resume/interview/recruitment world is interested in buzzwords and coolkids tech, not actually whether or not you can make things people want. (…)

 

System requirements
Developers expect clear requirements. Unfortunately, there is never a detailed design to follow, the problem I have touched shortly in my previous post Are developers like instrument players?
 

Expectations
Due to many reasons, developers expect their jobs to be revolved only around the code. Like the football player would just to just go onto field and “play with the ball”, without strategy meetings, watching how the other team plays.

One of the articles highlighting the problem is Expectations of a developer by Marek Zając (written in the Polish language).
The author is aware that developers often see their projects as a punishment, where “business” expect those developers to implement some stupid ideas in the old technologies.

Expectations are also discussed in 8 Disappointments of the Programmer: What You Should Be Prepared For on simpleprogrammer.com by Connie Benton, and a video Programming Job – Reality Vs Expectations by John Sonmez.

 

Coder required

Expectations. I think it all started with the demand for technical talent.
Writing code is a needed requirement to produce software, so companies small and big started hiring people able to code, not thinking how or who would put the code together into the product.

 

So let’s put code everywhere

  • We teach coding in schools and bootcamps.
  • We say ‘everyone should learn to code’.
  • We exam and certificate based on code and knowledge.
  • We talk about nuances of the code on blogs, forums, conferences.
  • We recruit based on code and knowledge.
  • We promote employees based on code and knowledge.
  • We idolize and idealize the “passionate about code” developer. (I dare to say it is more “addicted to code”).

Then we expect that the developer, spending months days nights and weekends of education about code, will suddenly code only 20% of his time, now focusing on debugging, meetings, documentation and environment issues.

 

The flow of satisfaction

Why “just coding” seems like the best job possible? Because it is a really satisfying thing to do.
Writing e-mails, drawing diagrams, sitting on meetings, configuring a firewall for the build server – something opposite.

“Flow state”, “The zone”, brings satisfaction to the developer. If you code, you most likely already know that state.

You can read more about those concepts on:

It is reasonable that a developer will not be super happy when those times of joy are taken away by meetings every two hours.

 

I’m smart and better than you

Another source of satisfaction in the development process comes from writing a very complex code or understanding a complex code.

After writing that complex code developer feels like he solved a difficult puzzle, and often the complex solution may be seen as a piece of art. Everyone reviewing that code will be in owe.

It also let’s use all of the knowledge developers are required to learn to get a job. It reassures the developer that he is good and employable. On top of his skills. Technical skills are measurable elements when applying for a raise.

Complex code is satisfying. That conclusion comes from the lecture given by Dror Helper on the .NET Developer Days 2019 conference that I have attended.

But often the thought process of a complex solution to satisfy oneself looks like:

Look at me! My creator really knows the language! I use default interface synchronized thread-local JavaBean copy constructors with custom generic unchecked exceptions and cross-functional security-hardened JAXB Lombok code generation!

from Why Senior Devs Write Dumb Code… by Scott Shipp.
 

If we encourage or expect complex code in our solutions, in code reviews, blogs, conferences, then we will face the consequences.
That approach pushes the software development industry into focus on the code above else.
 

Unfortunately, deliberate effort is required to make the code readable.
A developer needs to put down his ego and write a “stupid” code anyone can write.

On the field of “Clean code” we have a lot of publications (starting with classic Clean Code by Robert C. Martin), yet it is still something optional.
It is not easy to approach a senior developer writing unclear code, as it can be easily replied by “if that is not clear for someone that dev needs to get better!”.

 

Betrayed, despised, rejected developer

It is very natural for a developer to feel at least ignored when faced with a non-code task. With so high focus on the code, we produce scientists, artists, engineers, only to give them intern-level tasks.

Or out-of-skillset tasks. Most developers already know it will be not possible to meet the quality of a server configuration to the level of their coding skills.

Developers are the only ones to code and can make the non-code task as well (as any human being), so whenever IT/PM/BA/QA/UX are busy, developers “do their jobs”.
And that is something anyone can be angry about – doing someone’s else job.

In the end, from a management/team perspective, when a single developer is complaining about his tasks, it looks like that primadonna-developer refusing to do his duties but still trying to grab that paycheck!

Working isn’t fun, mommy! I wanna just coodeee! And moneeyyy!

 

‘Coders vs business’ world view can be amplified by natural protection to stay in the comfort zone, by both coders and business people.

 

Every coder is the same

Another reason to believe “code” is a cure to everything is thinking that every developer is the same, so adding more developers will produce more “cure” (more code).
Assembly line workers comparison was often a conclusion in the discussion at You Are Not Paid to Write Code on Hacker News.

Or that there are magical senior developers, who will solve every problem because “they are one with the code and code is with them”.

That kind of thinking may come from the musician/athlete’s understanding of a development job.
An athlete can rely only on his training, physical and mental state. But even a great musician will be seen as an amateur if the composed song he has to play would be really bad.

A developer is even more of a football player – playing with a team. And with high technological debt that developer will start a game losing 0:9.
Do you think a great developer alone can turn out the final score with an impossible deadline and team members he never worked with?
Without team trainings (product/technology/project), analysis of the other team tactics (design), tactical team members (devops/tools)?

 

Protection from the responsibility

However, with a shield of “just writing code” is too easy for a developer to hide behind it.
“Good requirements, meeting deadline, documentation, useful final product, team cooperation – those are problems of someone else – mine is just the code”.

While it often is someone’s else problem, it feels like there is no effort on the developer’s side to even try.

That is a bad requirement, give me better

Documentation is not clear, I cannot work with it

Well you can write the technical documentation yourself too

I am not a UI designer, users just need to learn the application

If my code has errors QAs will catch them, I don’t have to test

My approach to code is better than others in my team, ask them to get better and then we will cooperate better

You may not hear those directly, but those are thoughts going in a developer’s mind.

The other problem is:

I have just written method Y, I did not make a faulty software, the whole software is the responsibility of team leader, architect, analyst, tester, product owner, scrum master, client on UAT

While we allow developers to make those stands (because their technical knowledge is too valuable), there should be a dedicated person responsible for the results, and that person knowing developers “just produce code” and not a working product.

 

Cost of responsibility

It may not be obvious, but if someone has to fulfill any additional responsibility, more time and brainpower will be required.

If a developer becomes responsible for the build server, any required update will take time away from him for the update to be analyzed and implemented. If there is a problem with the machine, he will need to leave his current tasks to check what is happening.

Unfortunately, if a developer becomes responsible for the “quality” or “security”, it may often mean he will just be held accountable when something bad happens.

Responsibility is often proactivity. Every action in a project being evaluated if it triggers given responsibility.

  • Environment power outage – checking the state of services, state of saved backup
  • Training of newly joined developer – documentation for the team is always up to date so it can be used, and updating it while giving training
  • New feature implemented – architecture review if it affects performance or security – test cases consulted, analysis, documentation update, 3rd party e-mail sent

Every code action being filtered will slow down the development. It will increase overall quality for the “responsible for” parts, but a developer may feel not “doing his job” and missing deadlines when having a quite large number of additional responsibilities.
 

As we can see, standard and already estimated actions will trigger probably not-estimated actions as results, if we add “responsibility”.

Everyone being responsible for everything would require every developer to be an expert in all of the fields.

More business responsibilities like documentation and contacting 3rd party about an update to our interface will produce communication overhead if every developer will do the same thing for the first time (e.g. finding and updating 3rd party interface documentation, creating a meeting for 3rd party, sending an e-mail to correct people).

More reasonable would be one person to just review the code and features, keeping in mind that every change impacting interface must be consulted with 3rd party.

Writing code itself can be also a responsibility other than just developing a feature – following project and company standards for naming, language features, code structure, etc.
 

When becoming responsible for out of skillset task (which always happens in software development due to the novelty), it would be great to have training in that area.

 

Payment for responsibility

Having a developer performing design responsibilities and still coding may be solved by assigning a “Design” task from the backlog to that developer, and assuming 50% productivity for the main development part.

That way we can formally track non-coding tasks and see that the code is just one of many factors and parts of the whole solution.
Even small change in the code can be verified for required processes and responsibilities, raising from 1MD of code to full 9MD of work.

Making responsibilities more formal, they can also be managed by KPIs, if we put customer satisfaction points as KPIs, include application performance, user experience, enjoyable documentation, we may have completely different software compared to “ticket resolution times”.

Knowing how much time we spent on non-coding tasks, we can estimate projects better, and recruit better (candidates can be told exact numbers).

Summing up, we know that developers would produce unusable code most of the time, and we need some of them (seniors, leaders, architects or just anyone capable) to put everything together.
It won’t happen on its own, and requesting a developer to be responsible for something and not giving tools and time for it, is just “moving responsibility” mispractice.

 

Getting to the point…

 

Two types of a developer

One of the points to improve the situation for “business” and “coders” is to acknowledge two areas a developer can excel at.

On a blog post Two developer types written by Karol Wójciszko on his blog (Polish language) wedlugplanu.pl, author defines “Business developer” and “Technical developer”.
“Business developer” is finding the fastest solutions to the problem and trying to understand the business same time, while “Technical developer” follows all patterns and practices possible, budget or deadline being less important.

That article above allowed me to shape many notes and ideas in my head into this long post you are reading now.
 

Similarly a post on another Polish blog IT species classification Tomasz Sokół claims that there are “code developers” and “feature developers”.
The “code developers” understand every line of their code and used frameworks, they do not cooperate with business – they expect perfect design and focus on coding it. “Feature developers” try to create features the easy way, using frameworks, and they have no problem to talk with business.
 

Of course, talented developers can possess skills at both ends of the spectrum, some will be just right in the middle, but it is not realistic to expect every developer to be both very strong technically (providing results by the every possible and newest book in his coding language), but use that knowledge only when appropriate (there is a budget for that), and that developer would care for the all non-coding tasks.

Adding my observation, when “Code developers” do not follow all of the craftmanship rules and sometimes go for the quickest solution, let’s say they create a class with 1000 lines of code and no methods, they sure pack a lot of newest language concepts and make business logic too complex inside those classes.

Code developer can also be recognized in situations like:

A developer is asked to extend the current product with a business logic change, and the developer refuses, because the change, if implemented due to the deadline, would make his code ugly – the only other way is to refactor big part of the codebase to cater to the new scenario.
source: life

A developer is asked to update the installation documentation for the application. The developer immediately spots potential for the automation and writes a small application to be the installer. As a result, the installer crashes on every other machine without any logs, and the manual documentation does not work as it is still outdated.
source: life

A developer is asked about his effort in the project, and answers that he just did nothing, as he worked on another, more important project.
source: devstyle blog (Polish language)

 

Well, if you read the “About me” page on this blog, it screams “business developer”, and I would classify myself to that “group” happily.
I prefer to find a solution, look at the budget and deadline, discuss the pros and cons, quality, goals, and then progress with coding, even if not ideal.
 

A similar comparison could be “generalist / full stack developer” and “specialist”, where the first one is willing to switch between technologies, while the other one prefers to dig deeper into what he knows best.

 

Perception for different programmer types

The technical developers are often blamed for slowing down the project, reinventing the wheel, overengineering the product, refusing to go to the meetings, refusing to write documentation, etc.

Technical developers are also called “not a team players” when they are just not happy doing anything besides coding (for the reasons listed earlier in this article).

Karol Wójciszko in his post notices that mistakes can be done by either type of a developer, and I have seen it too often how great “coder” loses (the app is not working) to the deadline or business requirement, because “business/management” were his enemies from the beginning.
 

The business developers are perceived as unskilled and sometimes even called out “thinking like a manager”, and we know that is an insult to a coder.

Business developers might be mistaken as “not passionate enough” or even “not real programmers”.
 

More about those areas can be read on Enthusiasts vs pragmatists on Code Without Rules, like:

Enthusiasts code out of love. If you’re an enthusiast you’d write software just for fun, but one day you discovered your hobby could also be your career, and now you get paid to do what you love.

Pragmatists may enjoy coding, but they do it for the outcomes. If you’re a pragmatist, you write software because it’s a good career, or for what it enables you to do and build.

 

and The two types of programmers by Jeff Atwood, like

There are two “classes” of programmers in the world of software development: I’m going to call them the 20% and the 80%.
The 20% folks are what many would call “alpha” programmers (…) These folks were the first ones to install Linux at home in the 90’s; the people who write lisp compilers and learn Haskell on weekends “just for fun”; they actively participate in open source projects; they’re always aware of the latest, coolest new trends in programming and tools.

The 80% folks make up the bulk of the software development industry. They’re not stupid; they’re merely vocational. They went to school, learned just enough Java/C#/C++, then got a job writing internal apps for banks, governments, travel firms, law firms, etc.(…)

originally by Ben Collins-Sussman
 

To me, saying that titles like ‘Teach Yourself X in 24 Hours’ cheapen the craft is tantamount to saying, “Our club is full. Go away.” (..) “Newbies are ok, but they must first realize how hard this is, how hard we’ve worked, and how much more we know than them.”

originally by Scott Mitchell
 

The differences should be quite clear at this point.
Ultimately, which type of programmer should we strive for to join our teams?

 

Why not both?

There is no need to decide which “group” of developers is better, or that one of the groups must cease to exists as it not good enough for either business needs or true code craftmanship.

If we acknowledge the existence of two spectrums (and people being in-between or sometimes proficient both in technical approach and business-oriented approach)…

 

Then we can hire accordingly!

If we really need a technical person no matter what, no social skills, it is a decision for a company to make.

Of course, the recruitment process should vary for the expectation – if we expect someone to be more business-aware, we should not give that person trivia code quizzes, or at least not base hiring decisions on those.

And the job description or at least hiring interview should mention how technical the job would be (e.g. often demos for the client, documentation, business trips, assisting salespeople as a technical consultant – opposed to – writing a new system with new features based on detailed documentation from previous one).
 

I believe often information about maintenance and non-coding tasks is not mentioned in job offers because otherwise there would be no applicants “technically good enough”. Meaning, good developers would be scared of the offer.
It is obviously very easy to hire someone possessing 30% of required skills, downplay on the salary, and then expect remaining 70% too.

If we could post two job offerings (assuming we need a team of developers), we could create a team that compensates each other.

 

Search for job accordingly!

Same for developers understanding their needs.

If a developer enjoys exploring non-coding areas (e.g. cloud configuration, integration tests, documentation) and supports both coders and non-code business people, there is another match!

If a full-tech developer hates configuring CI/CD, and even more any kind of documentation, it should be said in the recruitment process. It would not mean you will not get the job – when assigned to the team, the team would know your preferences.
 

If we open more to clearly define jobs for “business developers”, “dev-ops” or even “maintenance developers” (to track difficult bugs in old projects or document them), those developers could have a career track to follow.
At this moment every job where coding new features takes less than 90% time puts that developer at disadvantage, as for promotion or changing a job, having fresh coding skills is a must-have (even for maintenance jobs).

Hiring an incorrect person will result in the developer leaving the job too soon to profit on his skills versus project training.

 

Hire really accordingly

Some companies use their developers to promote the company by writing blog posts on a company blog or by just being active in the community.

If that is a value being searched in a developer, his blog can be reviewed besides (or instead) of the GitHub profile.

We can go even further – have a documentation writing exercise during the interview. If a potential developer quits just seeing the task, we would know his documentation would be rubbish anyway.
It can be documentation to the solution created for the previous exercise or documentation for a larger part of the code/solution created by someone else.

User guide creation is something different than a technical document, and if you require developers to write that kind of documents, check their ability during an interview.

A developer can be asked about a critical production issue and fixing it “the dirty way”. If the company would benefit from fixes like that (SLA fix e.g. financial, retail clients), hiring code craftmanship purist will not be a good idea.

The example where specialization is even not needed – comment made by ImTalking

(…) Some time ago, I went for an architect role at a telco which was the largest Progress shop in the southern hemisphere.
The interviewer asked if I knew Progress and I said “No but that is only knowledge” and talked about successful projects and later found out I was hired because of that sentence (…)

 

 

Then we can give tasks accordingly!

Knowing we have people willing to do some non-coding tasks when required, quickly validate business ideas on meetings, or propose quick solutions to problems, we can plan around it.

Or have a self-organizing team, willing to take on every task!

 

Then we can promote accordingly! Resolve the seniority confusion

Knowing that there is more to development than writing code, the structure of the company can be organized around that.

Very often for a developer to be recognized is a promotion to a manager role. Things that make sense for factory-line companies often do not apply for software organizations.

Many of the developers prefer just coding, but still want to be rewarded for their achievements.
With raise, title, more responsibilities, but not very often by a typical management position. Survey done by StackOverflow for 2019 show that only 25% of developers are clearly interested in management carrer.
 

Unfortunately, the “senior” role is not an ideal solution.
I will dig into the “seniority” in another article I am preparing, but summing up, almost always a senior developer should be able to present a product in the sales, train younger members, lead small teams, discuss technical aspects with management and business. So becomes “business developer”.

Then if we reward the most technically aware person with that title, and that person will be as much soft-skills unaware as greatly technically is, then expect that senior to talk with business…
On the other hand, when we promote a regular developer that “has it”, other technical team members will despise the new senior, because he is “not technically good enough for that title”.
 

As a solution, we can have “Engineer I”, “Engineer II”, and final titles of “Senior Engineer” / “Principal Engineer” technical path.
Business-development mixed path with the title “Business Engineer I” etc., with final titles “Team Leader”, “System Analyst”, “Release manager” and I would even say “Architect”.
Full business positions will remain for “Business Analyst” and “Project Manager”.
 

Alternatively jobs can be categorized to “Implementer”, “Solver” and “Finder”, described on The next career step for Senior Software Engineers (that isn’t management) on Code Without Rules, based on original post Implementers, Solvers, and Finders by Randall Koutnik.

 

How to make it work?

First, we need to be real with our expectations and know what we want.

As companies, we cannot hire an all-stack-develop-manager, who will handle everything perfectly. If that developer exists, someone probably found that rare unicorn already and we do not have a budget for them anyway.
Then we must know how our software is developed, where problems are (design/development/integration/maintenance).

As bootcamp creators and universities – do not tell students interested in coding they will always write code in their jobs.

As developers, to know what we like, what we want to pursue and go for it.

 

Highlight other development aspects

If we want developers to have skills other than producing tons of code per minute, we need to be vocal about it in their communities.
Using podcasts, blogs, conferences, local or company meetings.
Discuss development processes, methodologies, clean code, teamwork, team building, architecture, business analysis, estimation, code maintenance, creation of products, etc.

Promote developer as someone who, in addition to having programming skills, understands software lifecycle, related fields (business, QA, project management, infrastructure), understanding patterns of software development. A problem-solver who can write code.

 

Code is just a tool

When you are creating financial reports using Excel, you are still a financial specialist, not a spreadsheet engineer. A spreadsheet is just a tool and concept to use.

In the article Please Don’t Learn to Code Unless… by Basel Farag, the author suggests, among other points, to not focus on the tool (code) when solving a problem.

We can look at the comment made by hpaavola

If you see yourself as a software developer instead of problem solver, you tend to solve all your problems by writing code.
In many cases problems can be solved by adjusting processes, improving culture, education or just by learning to use the current tools in more efficient ways

 

 

Value code and solutions equally

Beautiful code, smart code, performant code, they seem to be always better than working code. And working solution (putting all of the code together) is someone’s else problem. My part works so I am fine.

Real Artists Ship

is a saying attributed to Steve Jobs.
 

If we keep digging into code, we may never finish the product, and shipping the code is important. That part and many “not paid to write code” thoughts were shared by Phil Haack in his article We’re Not Paid To Write Code.

For example, suppose a customer calls me up and says,
“Hey man, I need software that allows me to write my next book. I want to be able to print the book and save the book to disk. Can you do that for me?”
I’m not going to be half way through writing my first unit test in Visual Studio by the end of that phone call.
Hell no! I’ll step away from the IDE and hop over to Best Buy to purchase a copy of Microsoft Word. I’ll then promptly sell it to the customer with a nice markup for my troubles and go and sip Pina Coladas on the beach the rest of the day.

Problem often is that regular developer would rarely suggest it to the client/PM/BA. And that is because default thinking is “code”, and feeling of being not in a position to suggest something like that.
 

It’s a unique experience to build a product of your own, from scratch, with no paycheck or deferred responsibility or venture capital to save you — you either create real value for your customers, or you fail.

If we would try to make that thought exercise in a way that our application is the only way we would make income next month, code would be least of our worry.
 

Recently, on the DNA Conference 2020 in Poland, one of the presentations was about software craftmanship. And the conclusion of the author, even summarized under the recorded video, was that software craftsmanship should be about improving oneself and providing business value instead of all the technological craziness.

 

Management to blame

Why we do even have a problem with developers required to understand business and the software lifecycle?

Just being more aware to produce better software is one thing, but often it is cheaper to have a developer do it all.

  • A developer can talk with the client, gather requirements, design the system, test the system and automate the testing, plan own work and give estimates on modules, it is all possible.
  • A developer will learn business analyst tools to fix the diagrams faster than the analyst would understand changes in the software.
  • A developer will learn to estimate his works faster than the project manager could understand the risks behind many technical concepts.
  • A developer can write test automation and scripts for the QA providing just test cases, in addition to his manual tests.
  • A developer can write documentation and guides, that is just writing texts learned in school, and faster than a technical writer having a knowledge transfer of the project.

Often all of that is required from senior developer/team leader, in addition to the most difficult technical work and team mentoring.

The need of that kind of abstraction has been explained in The Development Abstraction Layer by Joel Spolsky.

Some companies have all their business roles taken by ex-developers to ensure main programmers will focus on their tasks, not being asked simple technical questions too often.

However most companies are not even aware of the problem of expectations described in this article. A developer is a developer and has to do what is told by the manager, right?

 

Summary

  • Technical and non-technical skills are just skills.
  • Work where you are accepted and can improve.
  • Create teams according to the needs of the project (hiring correct skillsets and mindsets).
  • Assign tasks accordingly, knowing strengths and preferences.
  • If a team leader has to hot glue random code produced by technical developers not working as a team, he cannot have any other major responsibilities as this one would consume his life (and there is no way that leader would code himself).

 

Again, links to mentioned articles, as they are all worth reading as a whole:

 

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *