@Alessandro, correct and if I may touch upon your background for a moment, many, if not most, societies tend to pity those whoâve suffered from conditions such as depression or âimpostor syndromeâ. In the extreme case, classical thinking was that folk subject to either of these two were ânotâ capable of functioning day-to-day. However, as with most common knowledge, it doesnât automatically stand up to scientific scrutiny. There are several gotchas in that inference:
-
Empathy, in those whoâve battled mental health conditions in the past is orders of magnitude higher than the average of those who have not
-
[ex-]Sufferers react in a crisis orders of magnitude better than those who have never been through it.
And finally, one from âimpostor syndromeâ. Those crippled by it are operating on a different plane of perfectionism to everyone else. This is all loosely related to the psychological concept of the Dunning-Kruger effect (aka the cognitive bias of illusory Superiority), which is the flip side of impostor syndrome. This sort of cognitive bias is culturally split. The more âwestâ you go, the greater the prevalence of this effect in the population and crucially, the more east you go, the more prevalent the opposite effect (illusory-inferiority).
If you are suffering from impostor syndrome, your perception of yourself is at odds with the perception you have of other people, mostly due to what they convey. After all, if you see drivers all claiming to be above average and some may be, youâll consider they all are and so, reflect that you are worse. I use that analogy because it is the research that discovered illusory superiority. Research found that 70% of people think they are better than average drivers (average is 50% so 70% canât be better - otherwise youâre comparing different averages).
As with all research, these conclusions are subject to statistical variances of course, but are extremely surprising results, overturning a century of classical thinking.
The issue is that most organisations create very âextrovert-centricâ environments which set the yardstick for performance measurement. Extroverts are by far the greatest âperpetratorsâ of the Dunning-Kruger effect, with the bottom 12% estimating their abilities to be in the top 40%. Introverts are almost exactly the opposite. Hence, those battling self-loathing, illusory-inferiority and perhaps depression, are usually orders of magnitude better skilled than those who do not.
TL;DR if you significantly battle thoughts that youâre not good enough, science says itâs not you, itâs them.
Sorry for the long post.
Senior and junior are relative terms, relative to each other. This is important, because it shows why todayâs title inflation makes no sense. In a lot of places everyone is a senior with 3(!) maybe 5 years of experience. This is crazy. Where title these guys are going to pursue in 20-30 years (if weâll still have software engineering by then)?
I used to work at Nokia for six years and didnât mature from research engineer (not a junior one!) to a senior r.e. during that time. (Part of the story is that I wasnât very enthusiastic after a while and I was pretty bad at corporate politics, which would have been needed for the step, but only a few of my colleagues made this step in 5 years.) There to be senior, you had to meet criteria like:
It kind of makes sense for me now, 10 years later :) : a senior engineer is someone who can work autonomously (without much hand holding), which includes that they will seek contact and help when needed, add value to the organization without being told so (i.e. identify tasks/projects that make economical sense and make them happen) and also are able to help and guide other engineers.
It takes or should take a lot of experience to be considered âseniorâ. I donât think qualities and skills alone should be the metrics used to confer that rank to anyone. A search on job and salary boards can shed some light here as to how many years is typically considered to be senior, and it may well apply to just about any industry and role, not just computing.
A reasonably good hacker (in the spirit and sense of how Eric Raymond uses the term) can have all of those skills and qualities, and more, but you wouldnât want to give her the keys to the kingdom because she just hasnât amassed that kind of experience yet. What this means practically is you have worked across several different environments with different challenges, and that long-term exposure has given you some esoteric knowledge and intuition.
There is a clear distinction between an engineer and architect. These titles (letâs ignore developer, or otherwise that opens up a new can of works) are borrowed from industry and IMO very much abused and misunderstood in the software space due to the greater variety of software professions and barriers of entry. I believe you only need to look at the organizational structure of established tech businesses to understand this distinction.
The only exception is that an architect in this space is someone who has the kind of knowledge or experience to design stuff (systems, components, whatever) on a higher level of abstraction while taking into consideration all the pros and cons of design decisions, so it ends up being a more senior rank rather than a co-operating rank as in other engineering spaces. Such an architect could very well have experience in architecture alone and not (much) in development or engineering.
The CTO role is rather fluid, but does have its clear distinction. The CTOâs skill set is perhaps similar to either a senior engineer or architect, or an aggregation of both, but is more aligned with the business objectives from a technological, R&D perspective. Again, this means she need not be an elite hacker or have much development experience, as long as she can be a leader or decision maker. It usually depends on the kind and size of business. Startup culture has made it a habit to throw around C-level titles when in truth and practice they are not meaningful or useful.
I made a post to answer this question and would love to get some feedback on it here: https://www.codementor.io/manageit/career-development-in-software-86so2a19l
I think the main difference is experience. I can say from many interviews i made to hire new developers that junior developers tend to answer basic (and important as well) questions such as algorithmic questions and why we need multi-threading. As seniors may fail basic question such as why in c# Dictionary is faster than List when retrieving by key, they can answer when it is better to use the dictionary and when to use List. They may not be able to answer basic questions related to threading, but be able to provide better solutions for problems using multi-threading concepts.
The experience that seniors have helps them to provide more (Just Enough Design) for problems at hands as well. While juniors tends to use technologies more to just use them.
However, juniors are important in any development teams. They sometimes signale over design issues by asking simple questions about why we use this pattern or so. Also they are motivated toward technologies more than seniors, which opens the gate to enrich existing projects with technologies that may add considerable value to the solution and ignored by seniors as they may think it works without the need for such technologies
We say the following at my company:
Junior Developers write complex solutions to simple problems.
Intermediate Developers write complex solutions to complex problems.
Senior developers write simple solutions to complex problems.
A junior developer writes a code which works perfectly well in the current scenarioâŚ
A senior developer anticipates the possible changes in requirements and asks reasonable questions and writes the code keeping in mind that in the future the person who will maintain the code may or may not have the same technical skills and capabilities as the author of the code.
There is a huge difference not in the number of lines produced per unit time but the number of hours the code can exist without significant modifications and need for maintenanceâŚ
I donât think that âcommunicates respectfullyâ or âadmits mistakesâ are reasonable measures of senior vs junior; a junior can have those qualities from day 1, it doesnât make them senior⌠it just makes them pleasant, respectable people and great to work with.
As someone who is striving to reach a senior level, I would say that a senior dev is someone whom the business can rely on to make major decisions on things such as adopting new technologies, coming up with strategies for scaling etc, and is passionate about mentoring and guiding others.
My we have quite the array of perceptions and I really think thatâs what it comes down to. Itâs all about whoâs asking. Depending on the job and your skill sets you may be perceived as a senior developer. IMHO I believe that a senior developer can conceptualize the âfullâ stack of the product they are working on without writing any code. They should also be able to elicit their conceptual thoughts in geek speak for the tech savvy and plain English to stakeholders. Lastly I agree with the shit/fan factor. They should be savvy enough to find multiple ways of skinning a situation which can only come from humbly failing through their own eyes or learning from others. At the end of the day it depends on who is asking.
As someone that has been all three including CEO, experience separates a junior developer and senior developer. An architect is someone that obtained his position from brown noising someone and that position is normally a joke. A CTO has decided he couldnât hack being CEO or someone decided for him.
A Senior Developer, Software Architect, and CTO are more than just technologists (i.e., Software Developer and/or Analyst and/or C-Level Executive) . They are responsible for identifying functional requirements, finding the right technical choices, breaking problems into small manageable solutions that solve the big problem(s), clearly communicating with co-workers on all levels, providing honest feedback, predicting problems before they happen and design software correctly during the first attempt. Goals are identified first, not resource limitations, and the best alternative is chosen based on the business needs and project planning. Sometimes, one person is the team and he/she must do everything correctly. if you want more details, email RocketScientist008 (at) gmail (dot) com
Well, Iâd say if the difference is âonlyâ that, I should really get paid as a Senior, as I always end up covering all those tasks almost anytime :D
People who know me know that Iâve been bordering depression and self-loathing in personal life for quite a while, but when I started working on bigger projects I discovered to have notable leading, planning and motivation skills, which in turn are changing my life and career perspective more and more, like an untapped potential.
I feel that money is only a response to the software development goals and the value placed on proper software development. Guidance, leadership, respect for scalable software development process, ability to match technical solutions to business requirements, creative thinking applied to problem solving are also pre-requisites to a Sr. Developer/Architect/CTO leading a company and/or software development effort. Many people can design, develop, test, and implement code. Some people can do it better with certain design patterns and/or code optimizations. It takes a special person to think outside-the-box and build code that does not have to be refactored when business requirements change. A CTO (or Software Architect) worthy of their title is one who can find the best solution to any business and/or technical problem/business need(s).
@Alessandro, correct and if I may touch upon your background for a moment, many, if not most, societies tend to pity those whoâve suffered from conditions such as depression or âimpostor syndromeâ. In the extreme case, classical thinking was that folk subject to either of these two were ânotâ capable of functioning day-to-day. However, as with most common knowledge, it doesnât automatically stand up to scientific scrutiny. There are several gotchas in that inference:
Empathy, in those whoâve battled mental health conditions in the past is orders of magnitude higher than the average of those who have not
[ex-]Sufferers react in a crisis orders of magnitude better than those who have never been through it.
And finally, one from âimpostor syndromeâ. Those crippled by it are operating on a different plane of perfectionism to everyone else. This is all loosely related to the psychological concept of the Dunning-Kruger effect (aka the cognitive bias of illusory Superiority), which is the flip side of impostor syndrome. This sort of cognitive bias is culturally split. The more âwestâ you go, the greater the prevalence of this effect in the population and crucially, the more east you go, the more prevalent the opposite effect (illusory-inferiority).
If you are suffering from impostor syndrome, your perception of yourself is at odds with the perception you have of other people, mostly due to what they convey. After all, if you see drivers all claiming to be above average and some may be, youâll consider they all are and so, reflect that you are worse. I use that analogy because it is the research that discovered illusory superiority. Research found that 70% of people think they are better than average drivers (average is 50% so 70% canât be better - otherwise youâre comparing different averages).
As with all research, these conclusions are subject to statistical variances of course, but are extremely surprising results, overturning a century of classical thinking.
The issue is that most organisations create very âextrovert-centricâ environments which set the yardstick for performance measurement. Extroverts are by far the greatest âperpetratorsâ of the Dunning-Kruger effect, with the bottom 12% estimating their abilities to be in the top 40%. Introverts are almost exactly the opposite. Hence, those battling self-loathing, illusory-inferiority and perhaps depression, are usually orders of magnitude better skilled than those who do not.
TL;DR if you significantly battle thoughts that youâre not good enough, science says itâs not you, itâs them.
Sorry for the long post.
An architect will make sure the code implementation and architecture are always aligned with the business logic and goal of the team. Making precise trade-offs is another essential skill for software architects. He/she should also equip other team members with this mindset, so the team can grow.
I agree and believe that a good architect should also be hands-on, even if he is the entire team. Every environment is different, but successful software development is mostly based on the Principal Software Architect/Team Lead/Sr. Software Developer/Systems Architect making the correct choices to match the business requirements with the company resources.