I changed my opinion after a workshop on different team roles at my previous job. A lot of it was boring workshop fluff, but I loved the core message: that many personality traits aren't purely positive or negative. Perfectionists are nitpickers. Fast developers are sloppy. Experienced ones overthink stuff. Bleeding-edge evangelists ruin long-term stability etc. There are two sides to every coin. We tend to value traits we have (or desire) and judge people based on that, but it really depends on the team and the task.
Need a quick-and-dirty prototype ASAP? Give it to the framework hipster. Planning architecture for a complex long-term project? Ask the boring slow guy with 20 years experience. Build teams with enough variety and try to solve problems through process. Don't scold the fast guy for being sloppy, give him tasks that require speed and solve bugs with better QA and tests.
TL;DR: A damage dealer will beat a healer one on one, but that doesn't mean he's better. You need them both (plus a tank) to run a dungeon successfully.
Basically it said that loads of time and effort is wasted by managers trying to fix the flaws of individuals. The alternative, they argue, is focusing on building teams where the members bring complementary strengths to the table, and then working on how to make the most of an individual's strength in relation to the context of the group.
Let's optimise the throughput of the team instead of maximizing the resource use of individuals. Just because you maximize the the amount of code written by each individual doesn't mean that you've optimized the throughput of the team: sometimes the opposite is true. They're orthogonal concerns, but they're treated as if the former magically creates there latter.
As you get experienced, I think it's beneficial to be able to learn to be both fast/sloppy and slow/meticulous given the circumstances. Having worked in both enterprise scenarios and startup environments, I've learned that it's really a result of larger environmental pressures.
If you're working in long-range software, it's by far more beneficial to be a bit slower and more meticulous in your approach. What you're really looking for is incremental improvements that have large impact because the scale or importance of the project is already established to be very big. While you feel like you're not getting much done, the impact multiplier in these situations is very large.
However, when you're in a startup environment, you don't have any value in the product yet, so you have to move fast. A few bugs here and there are not really a problem since you will probably redesign and revamp different features. Testing is a lower priority and you feel like you're moving a lot faster as a developer.
I think healthy teams have a healthy spread on these trade-offs, centered about around the maturity of the team/product/company. Tension between the two sides keeps things moving forward and allows adjustments to keep the machine moving forward as best it can.
The 10x developer that isn't actually a 10x developer, but continually gets to start projects! So they get to do that part where you can make 80% of the program in 20% of the time. They slap it together, and move on to the next big thing. Leaving everyone else to clean up their rushed mess that barely works.
I hate that I work at a big company and we get into new project discovery mode and then take 3-5 weeks to code up extremely over complicated prototype programs. But they have tests (usually more than code), they have "good design", they have code that's reviewed and sent back at least thrice, they're stable, they've got monitoring, ... And they take huge amounts of time.
The one quality all of that has is that everybody agrees it's a good idea. When trying to quantify what that means ... I completely fail.
The design always fails to account for something. I have had it happen once that the initial design actually lasted to "v1.0", in 3 years. So I'm becoming unsure what makes a design good, except everyone agreeing that it's good and a certain "clean" look there is no difference between a good and bad, clean and messy, thought through and ad-hoc. Good designs don't survive a few feature iterations any better than bad designs, but they impose lots of extra costs on feature iterations. And that's assuming people don't make the mistake that turns the best of good designs into horrible designs : sticking to it. Attempting to fit new features into a design that didn't account for them can make the most beautiful design an utter disaster.
Same thing about reviews. Reviews seem to make people make huge changes in one go, because that feels much better if people regularly argue about much of it, compared to having to redo a change that by the time it's reviewed 5 other things depend on, where you get to throw out the 5 other things. And of course fairly commenting on huge changes is not done because pretty soon you'll feel guilty about the amount of work you're causing. Which is exactly why people have a better experience making huge changes, of course.
Tests ... never prevent bugs. Now I'm not saying tests don't have value, but the current testing culture is utterly and completely broken. I've simply decided to hack the system : a cli to your methods that allow you to quickly do ad-hoc tests and record them into generated code. Why ? First, it allows you to test against real-world data, which means your idea of what your code does actually meets real world data instead of artificial cases that may miss the point in the same way your code does. Second it allows you to quickly regenerate the tests if there is some big change needed. And thirdly it completely hacks the system. Getting coverage is trivial. And your LOC stats will be through the roof. Double bonus if you do this for less-than-expressive languages like C and Go, it's less necessary for things like Java and C++.
But "best practices" seem to make everyone happy in big companies, make everything take very long, and because of that very often cause the failure they're trying to prevent. It's like in chess : people like "safe" moves once you've beaten them once or twice. And in 10 moves or so they get themselves into a situation where they have to give up that safety, and your "haphazard" moves turns out control 80% of the board and fighting from that situation is not going to go well. But it's the desire for safety, the fear of loss, that's exactly what's causing their loss. They don't see things this way, though. If only they'd moved this piece to cover that as well, then it would have been fine. It doesn't even seem to matter if you show them that no, it wouldn't have been fine. That the issue was their attempt at securing what they did resulted in a complete takeover by the other party.
And every attempt I make at changing this fails, often with people having emotional breakdowns and complaints. And then their projects fail, again and again. Multiple times people have been very angry at me for providing a solution to some problem they were doing a 2 year project, restarted from scratch 3 times, for by writing a 300 line script that utterly kills interest in their project because it works and solves the problem. Apparently that "violates trust".
I don't understand why businesses want this. It keeps the peace, yes, practices like this, at the cost of efficiency, at the cost of developer sanity (developers wash out after about 5 years despite the current employment conditions, and often become non-developers. Hell, several people I know became accountants and prefer it over software development. Seriously).
And despite this, people seem to further down the rabbit hole every time I seem to look at it. WTF ?
What if we're in finance industry working on critical systems and a bug mean millions dollars lost? Should we hire "sloppy" at all? I think not.
...unless you've an R&D department dedicated to experimenting — non-critically — with myriad, "creative" algorithms or solutions.
Then, hey, don't give 'em write permissions, but let 'em read and let 'em rip!
For maintaining business critical systems? Obviously not.
But not everything in the finance industry requires that sort of stability and uptime. There are needs around prototyping new products and services for customers, for example. Not to mention ferreting out Excel spreadsheets being used in unconventional ways and creating intranet web-apps to better fill those unmet needs.
Just like sharks and pilot fishes.
I haven't played a single game where this was true. Simply because both the healer and the damage dealer can do damage but only a healer can heal.
Put another way, two healers vs. one damage dealer are more likely to be evenly matched than the other way around.
So that he can make the prototype with the newest hipster tech that noone else knows in the company and will probably be abandoned next year...
This developer sounds humble. That's the most important quality a developer can have. If one becomes too humble (impostor syndrome) then one needs an environment of more encouragement. That's the job of peers and managers.
There are lots of bad developers. It's not unthinkable that this guy is a bad developer - but it's still the managers problem. Is he trained, mentored and encouraged enough?
For some, it's exercise, reading a book, working on a side project, cooking a nice meal. For me, it's playing music -- an activity that's intense enough that I simply have to exclude all thoughts of the problems at work, and engaged with people who don't give a rat's arse about my job.
I'm not sure if I'm humble. I sure as hell am not when I'm interviewing but I blame that on American culture.
Thanks for the feedback! :)
I was on a team once where my diagnostic skills put me near the top of the stack for being given hard-to-find bugs. What that meant was that sometimes I would ship one commit a week while tracking down several difficult issues. Does that make me a bad developer? A slow developer? Or are those even valuable distinctions in this context?
Rather than trying to be better than everyone (anyone?) else, try to be better than you yourself were last week, or last month, or last year. That's the only consistent variable one has across all the kinds of tasks we are called to perform in this role.
A good management team will recognize these skills in people and assign them appropriate work.
All people are not the same, that's why we have developers and doctors and fireman. All developers are not the same, that's why we have backend, frontend, Java, C++, etc. All backend developers are not the same, and so on, and so on. People are not pluggable assets.
Well, there is a countervailing force in that companies don't want every developer to be a SPOF, giving the company a "bus number" of one no matter who gets run over (the typical definition asks if any single developer is a SPOF, rather than every single developer being an irreplaceable special snowflake).
That said, if you work for a company that leans too far the other way and values process over productivity, hammering every square peg until it can be wedged into any of the round holes (instead of enlarging the round holes to make them square), you may want to consider looking for a new employer.
Of course, realistically few devs are so critical to a project that they couldn't be replaced by another strong developer with a month or two to learn the code base, or at least a part of it. Obvious exceptions for deep domain expertise and the like, of course. But I've worked on way too many rescue projects to believe anyone is truly irreplaceable in the normal course of events.
Great quote ! The best solution to impostor syndrom.
By accepting a job from them, you're obligated to work diligently at a sustainable pace. You aren't obligated to worry about whether you're more productive than your peers.
I posted a link to Beppo the road sweeper's monologue from Momo by Michael Ende in a thread on a time management story a few days ago, but I'll link to it again since it seems relevant: https://www.youtube.com/watch?v=8Q_JYYcBP2Q#t=15m05s
It's also worth considering that not all developers are easy to replace, for various reasons. A lot of big companies aren't in a position to be choosy as long as their employees are reasonably competent and can do the work.
This behavior is totally normal in this industry and if you get put in a situation like that you have to do the same. No one can concentrate for 40 hours every week on development without getting burned out.
The reality is most people are probably lucky to get 20 hours of productive work done a week.
Sure it is. Impostor syndrome is defined as the state of affairs where your emotional assessment of your competence is lower than your actual competence. The definition does not depend on which aspect of the task is being discussed. "I can't write code" (when you can) and "I'm too slow" (when the people who appear faster, are doing it by just sweeping bugs under the carpet) are both impostor syndrome.
I will add that by the sound of things, the reason you have impostor syndrome is because your previous bosses have been bullies, sadists and sociopaths who successfully accomplished their goal of damaging your morale for their own pleasure. This is sadly not a rare state of affairs, but it's not universal either. Never be reluctant to look for another job if your boss is an asshole.
a) people who lack the insight to realize it, and thus don't work to fix it
b) people who realize it but don't care (for various reasons, some valid some not)
If you're agonizing over your job competence and trying to improve but feel you aren't succeeding, then it's vastly more likely that either your job specification is impossible, or you're setting unreasonable personal goals around your job.
There's also a chicken and the egg issue here; perhaps the author really does not enjoy coding and thus is not willing to put in the effort to improve?
None of that is in question, but let me ask you this: are you a professional basketballer?
I'm not a professional chef, read into that as you will.
It's very possible to be bad at something AND know that you're bad at it AND not be able to reach the proficiency to perform the task at a professional level.
Also, it's pretty clear that I can read. If you are going to insult me, it's better to insult my comprehension or argumentation. However, I would argue that it's generally better to just not insult other people.
You forgot to add "AND still be employed in that capacity."
When I doubt my dancing skills, it's a rational evaluation.
Also, a lot of this is just management trying to put pressure on the devs using methods more appropriate for a kindergarten. I vividly remember my former boss telling me "you are going to put down the team and have a bad conscience if you don't finish this feature on time" (an arbitrary deadline caused by a looming performance review). He was a good boss, but I would have more appreciated an honest "look, I'm trying to get you a raise so finishing this feature by this date is in our mutual interest" without any kind of moralizing shit.
When asked to account for your time, use the opportunity to be good at creative writing. Give the most flattering and awesome impression about the time you spent.
Being competent is a pride for yourself only, for all others is whatever they want to see. Always act as if you are making less than you should. Act as, not be. Never stay working late, never work on weekends unless you are the one benefiting.
The value you give yourself will be the value people will give you.
Everyone else only has a very high-level concept of whether they think you've been doing what you're supposed to do. The optics on this must be controlled. You do not want to be one guy in the hierarchy away from getting shitcanned because everyone except your immediate boss thinks you don't finish enough tickets or whatever.
Look better than everyone else. Employment is a popularity contest. To succeed in a career, do your job well enough that you don't get into trouble, and spend the rest of your energy on social and optical development.
I must say, however, that "working overtime" (that is, sitting in your chair and looking fancy until 8pm at least 3 nights per week) is a near-necessity for someone looking to climb the ladder in most organizations. Since people don't know if you're doing a good job or not, the amount of time they see you in the office is a big component of their evaluation. They assume you are working if you are butt-in-chair. You need them to think you're a hard worker. You should never be the first one to leave unless you make sure everyone knows it's a special event for which you cleared PTO approval process, and you should be one of the last to leave at least 3/5 of the nights.
This passage of text should be passed to every employee at every job ever on their first day.
I've been forced by managers to merge or even ship features that are half-way done.
I have to agree with other people advising you to switch to another place.
If you are working in a toxic environment, or you don't agree with or like how they handle the projects, then there are better places for you to be.
Don't be afraid to pursue a better workplace environment if that's what matters to you.
Also, talk to your colleagues. See if they feel or see things the same way. Once you realize you're not the only one in that position you'll feel better about moving on.
Come to thing about it, a long time ago I worked at a place as a development team lead, and I saw management doing similar things to my team members as what you're describing. I confronted the owner about that, but things didn't change. I then advised my colleagues to look for something better and so did I (even though they always treated me great). And I'm happy to say ten years later we are all happy we left, and we all know we don't want to work somewhere like that again.
I confronted management about the time tracking but it was one of my first jobs so I had little experience with that kind of thing. The job was a nightmare in so many different ways that the time tracking was the straw that broke the camel's back.
And one day I gave up. It was hard to hear all the time something like "you are too pessimistic, why you always say that we cannot build the Tardis in a month?", or "You are too slow, you see that guy in the corner? He is ten times faster then the whole team (and he is happy working in an open space). And now the whole team will be fixing the thousands of failing tests (caused by this guy) for the next six months. Because if they will be red, I won't get the yearly bonus.". The latter is real.
So I don't care anymore. My side projects are opposite. So I build them slowly. Very slowly. And I learn all the things around them.
Now, my major background task for 2016 and 2017 is trying to analyze how to become a better developer with myself as a guinea pig. I'm still putting things together, but "faster in the development environment of choice" is one stumbling block. These are the major issues I've found:
1. Being fast or slow only has a minor correlation with good code, but there are confounding issues. Good code takes different habits to write than bad code.
2. People who are fast at coding have an ingrained series of patterns on which they rely. They slow down when they are pulled out of their element, as can be expected. As such, there are meta-skills that contribute to speed, but a large portion of it is having a series of reliable patterns to solve the problem.
It turns out most tasks are the same on the surface. Spend time getting those patterns at heart.
3. Fast developers have a deeper knowledge of the libraries around them. We underestimate the overhead of research, even with google.
Spend some time exploring the corners of your libraries and frameworks and languages. If you work on the front end, you need to have the ins and outs of the client memorized.
4. In general, fast developers may not realize it, but they're methodical in how they approach problems. They have an internal checklist. Develop your own internal checklist.
5. Because they are fast, they have more confidence in developing tools that speed up the general issues that slow every developer down. (setting up environments, test data, and the like.) Laziness, it turns out,b is as much an byproduct as a cause. If you are slow, the ROI on developing tools might indeed be outside the timeframe of efficiency. Work on getting faster, and you will see more opportunities to consolidate your work.
I'm still working out the solutions of how to teach this in a generalizable fashion and how to back this up with research, so don't take these as gospel and I'd be particularly interested in fast programmers who have alternative perspectives.
I finished reading the post but cannot figure out what OP is trying to say. The title doesn't match the content. At first it sounded like it was one of those rant posts exposing the employer for mistreating, but then at one point it sounds like OP understands that he is a bad developer (because everyone tells him he's slow), but then goes on to talk about whether it may be the manager and not him. And then ends with some random conclusion about nothing. It's almost like watching an episode of Seinfeld--it's a post about nothing.
Then again, if a company hired someone who's so obviously bad that everyone thinks he's slow, it's their own fault and must be a bad company. Explains why they make him track time and all that stuff.
How I dread logging the hours there! Especially if it's a day or two after the fact. The items will often be specific features to be developed. And so I sit there, with the time sheet (and 20/20 hindsight, of course) asking myself: "How could you possibly have spent that long finishing it? It had a low estimate! Better round down so they don't think I'm an idiot. Who in their right mind would pay someone XYZ to add a lowly checkbox in the corner? I wonder how many hours Bob logged for that radio button he worked on. Those guys outside have emptied half a street's garbage cans in the time it took me to look up this API."
Of course, it's probably mostly in one's head. Like the author I don't really get negative remarks on performance, and consider myself a reasonably decent developer. But even so, the task of painstakingly journaling every half hour worked seems incredibly demotivating sometimes, for presumably no other reason than being a great time to second-guess everything you did.
I love the details of it, I love how I build up detailed description of what I do as I'm doing it. I think I've had one bill quabbled with about 4 years ago which was me taking too long to write up the change log.
I khow getting time tracking forced on you from above would be frustrating, especially as management would probably abuse it. However I think that it's a shame, I love the transparency of it.
The time-tracking we did was real-time. You sit down, you press "play" and you're tracking. The added bonus (oh jesus, I forgot about this one) was that your status was visible to your manager at all times.
Anyways, thanks for the thoughts!
I do everything by the book, but in the end, everyone else does more.
I did notice that they're cutting corners, but then I tried to do it too, and I was still slower.
So, I'm still asking myself, am I slow or am I a perfectionist? I'd like to think it's the latter, but it may very well be that I'm slow.
My defense in my mind is that even cutting corners I try to do the important things right. It may be a lie I tell to myself.
That's pretty much what I got from this post, self-doubt.
Try a few simple projects (eg: making flappy bird clone, or a simple HTTP server) as fast as possible and screen record all the time you work on the project. Then review the project and recording for things that slowed you down (eg: going down rabbit holes, or your tool-chain is too complex for the task at hand).
After that, do the project over (or a similar project) and try to beat your previous time. The only thing that should matter is the amount of wall-clock time until the project is minimally useful, eg: time to a browser accepting a static webpage, or the game minimally playable.
If you have trouble parting from the book way, an HTTP server might be the better option as there is the "book way" on how its supposed to be done, and what browsers will not vomit all over. Go for the browser rendering a page or two with no visible errors with dev tools closed rather than passing a comprehensive test suite as in the end the only thing that matters is "did the user notice the missing corners".
If you can do this when you intentionally tried, it means you're a perfectionist.
If you cannot no matter how you try, it means you're bad.
It's important that you try this out and actually find out who you are, unless you can't do it because you're too scared.
If you find out that you're a "perfectionist" and that's why its slowing you down, try to learn how to balance. People never doubt you unless you're consistently slow. I am sure what happened to OP was he was consistently slow. It's extremely hard for a manager to just tell people they're slow, and this guy heard it multiple times, so it probably means he IS very slow.
Every programmer knows it's always not as straightforward as it looks from outside. Sometimes sou would come across a task that looks like it would take 30 minutes just to find out it's much more complex than that and it takes up your entire week. But sometimes it looks like it will take a week but turns out you can finish in 30 minutes. That's why most people tend not to judge you for being slow sometimes. It's only when you're ALWAYS slow that people doubt you.
Think about this for a moment: you say you do everything by the book but everyone else does more--have you ever thought if it maybe the case that these other people also do things by the book?
If you have doubts about yourself, you should really proactively figure out ways to tackle this. In most cases it's not because you're stupid, it's because you have bad habits and you just think it's natural.
But he had one quality that I really appreciated as a lead: he persisted in what he was doing until he got it done, and without complaining or needing any prodding. So I actually did not mind much at all that he was slow, because I could "fire and forget" him at something that was important but not urgent.
In fact, the main problem I had with him, was that sometimes he would get really angry about some code or a bug, and slam his fist on the desk and/or swear. I mentioned it but you know how code is, when you're really engaged with it, the process can be emotional, and it was hard for him to temper those impulses. It was never really bad, although I was aware that not everyone wanted to pair with him. Which was fine, we generally worked around it, but when allocating tasks, he sometimes got the short end of the stick because of it.
Everyone wants their employees to be the trifecta of talented, hard-working, and nice to work with. But most employees are missing one of those traits, and some are missing two. You sound like a diligent worker but maybe not a genius. That really should be okay for both you and them, and if your manager is good he will appreciate that. But consider, are you nice to work with? If you have a choice, maybe spend your effort that way, instead of worrying that you're not talented (enough).
So until such a talk happens, don't worry about it. Just keep on keeping on.
God, I love Seinfeld so I feel a little flattered by that! :)
The article is more of a musing about an insecurity than anything else. But as to the content, maybe I can explain a few things better:
1. The management WAS bad. The job where I was time-tracked was a nightmare in so many different ways. However, it instilled a sense of insecurity in me. A single comment from a manager at a completely different company brought all that stuff back up and ever since then, I haven't been able to put my mind to rest about my own performance.
2. Developers are often quick to blame management for problems without considering that THEY might be the problem. So I mentioned that when someone tells me "The management is bad if you're missing deadlines", it doesn't make sense to me as a blanket statement.
3. I concluded with saying that I have certain abilities that I recognize as good but I'm still wondering if that's enough or anywhere near enough.
Thanks for the feedback though! I'm trying to do better with writing this type of stuff so that it's as concise and self-explanatory as possible. Looks like I still have more work to do.
The driving overall concern is avoiding points of grinding minimal efficiency for individuals, and in near all cases that can be avoided via some combination of simple strategies, even when you are the only person on your own personal project. Development is such a huge space that no two people will overlap completely in skills and experience on a team, and pulling in other people to alleviate your dead ends is a part of how you learn specifics needed to avoid that dead end in the future. But it is knowing to pull people in or seek another path that is the important part, not the specifics.
Working to an absolute dead end is only useful in the sense that you then understand better the incentive to avoid doing it again if you can.
An alternative view on the same problem space:
What exactly does that mean. I'm not saying this isn't a real thing (I really have no idea), but the only time I've heard the phrase used in person was by people who get ahead by posturing.
When someone uses it sincerely, what do they mean? What does it look like, as opposed to not boxing your time? What specifically does it solve?
A technical analogy would be depth-first search of a solution space, e.g. in a simple chess AI.
If the search has a cut-off depth = deterministically bounded length of search time = time-boxed
If the search does not a cut-off depth = unbounded (potentially infinite) length of search time = not time-boxed
- So it says in your CV that you are quick at math.
- Yes. Yes I am.
- How much is 23 times 14.
- That's not even close!
- No. But it was quick!
Bad employers are also a thing, and is much more frequent than most people realize. They usually drown you in tools and processes along the way and without much development experience its hard to tell whether they're bad or you are.
You're going to hear about Agile, TDD, code metrics and whatnot. Its all superficial at best and those promoting them don't usually have quality products on their hands to begin with, or have codebases much larger than actually needed. At least from my experience its that way.
Its best to find an employer who can help you grow instead of fitting you in a box.
But the other side of that coin is that my code generally works correctly, and rarely (I wish I could say never) needs fixing later. My managers and customers know that my code will work 'as advertised'. My colleagues tell me they enjoy working in code I've written, because it isn't a mess and it feels logical and well organised.
But hey, I'm a little slow. And in ~ 25 years of writing software for pay, only one manager I've worked for has ever had an issue with that.
I replaced $girl in a sysadmin/programming role that would get used by other employees. According to my supervisor, she was always far more productive than me. He'd ask for an estimate of how long something would take and he'd always say, "That's too long. $girl could do it half the time."
Well, because it was my first tech job company, I sort of had impostor syndrome because of him but also thought of a way to test it out. One job we often had would get programmed from scratch several times a year and take about 2 or 3 hours to do. I cludged it into a simple framework where I could just edit the XML after the other employees started to use it. So when he asked me how long it was going to take before people could start using it I said thirty seconds.
"That's too long... $girl could do it 15..., wait, what?"
Management often assumes that they did their job when they handed in specs.
And I often assume that there is nothing else for them to do.
As for the slipping estimates, are you part of the process that generates them? If not, it's back into "your managers are bad at their jobs" territory.
And you shouldn't beat yourself up about bad estimates. Everyone sucks at estimating. (Read "Thinking Fast and Slow") Which makes sense since we are estimating how long it will take us to make something we've never made before. Everything breaks down into day or week or weeks or month or.... You could also take 4 weeks to fully define every requirement and create tests for validation for a task that would have taken you two weeks.
You are a bad developer if you keep making the same mistakes or if you don't spend anytime learning new concepts/languages/processes/etc. You are a bad developer if you approach your job as doing exactly what you're told and not caring or thinking about how your contribution is part of the bigger project.
I found time tracking tools to be hugely beneficial. It changed my focus, and forced me more aware of what I was working on. I am, however, a slow developer sometimes. It is just who I am.
I found that often employers look for 'smart' candidates, instead of SMEs. This is their fault. If they were interested in / could afford a subject matter expert (SME) then you wouldn't likely be working there. If you are an SME, then you will likely produce results/prototypes far faster than others. Smart people take time to learn, thats how they got there.
Because HTML and it's various implementations/versions are a Byzantine mess.
'Web development' is not so much development ... it's about knowing a myriad of little, innocuous details regarding various platform, api quirks, toolchain bits etc..
The 'development' part of web-dev is usually quite straight forward - you're not doing complex AI etc..
And fyi - development is 90% struggling through things you don't understand, bugs, hiccups etc.. A good chunk of the code you write like English. It's all about working through the pain points, making 'aha' realizations about how you structured something, or about some crazy API quirk. That's the job.
I ended up leaving. Sometimes, the job is too good for you, and sometimes you are too good for the job.
That is simply bullshit. Don't take anything they say seriously except the broadest interpretation of what the project is.
It sounds like the writer has something north of basic competence. In that case, just do your job mostly your way and don't give a fuck what the others think. If THEY don't think you're worth your price they won't keep paying you. It's really as simple as that. And if you do find yourself out on the street then you can sit back and try to decide how to partition the failure between yourself and the company. If there's any blame you can clearly put on yourself then work on that. Otherwise just assume it's them and move on. The longer you work in the field, the more you can assume you don't suck regardless of what people appear to think.
In other words, actions speak louder than words or even company policy. If they're keeping you it's because you're valuable regardless of what they say.
There are too many bugs in the code. Okay. Why? Well we don't have good testing set up. Why? Because time was not allotted for writing test code. Why? Because it was rushed. Conclusion: You either pay the cost up-front or after-the-fact. Either way. However if this is a constant thing then the real problem is: "You have too many features being built for the size of your team, either increase the size of the team, reduce features, or prepare for big problems."
From personal experience I can say me working at "optimal" power, that is optimal sleep, no external life problems, not sick, generally very happy is maybe 30%-40% more productive. That seems like a lot, but if you need 500% the productivity, you ain't gonna get it by making a person feel like junk, not get needed rest (vacation / day off), not letting then handle family issues, etc. I can get a developer working at 100% more productivity, but only for a short amount of time, then they burn out which requires EVEN MORE rest time.
For a small company, this is probably the rate at which you ship features. Good developers ship enough that there's pressure to constantly explain the improvement to sales / marketing.
For a larger company, this is probably a user metric. Are this things you're doing moving the needle on logins, time on site, repeat visits? You should understand what areas of the product are high value, and which are experimental. You should spend your time converting experimental features to high value features. Polish and edge cases.
For a bigco, this is probably scaling metrics, like page load time and uptime. You should have clear targets you're working against and be able to prioritize against that target. Numbers are easy to show results against.
Anybody can be fast against sprint points. You need to understand what the business goal is and play to your strengths against that goal.
Why don't you try charging them 10 cents for each trip through your code? Lawyers do that, and feel like it's okay.
I have since realised it had nothing to do with my actual performance. It was a people thing.
Turned out he wanted to be the boss —that was made official 2 months after my arrival. On my very first week, he started to make disparaging comments under the guise of joke (or were those real jokes?). Those soon occurred daily. Sometimes in front of the client, who (surprise!) eventually lost trust in me.
If this was my only experience, I would have thought it was me. But I have since received enough external validation about my skills (people looking up to me, actual results…) to know better. For some reason, the guy could not stand me, so he got rid of me. Another small detail: he never smiled at me in the morning when we shook hands to say hello. He did smile at everyone else.
If you lean more towards a test driven approach backed with trackable metrics for code quality, I think you might have more confidence in your day to day development and ultimately be more productive.
I ask this out of genuine curiosity but do you have a cite for this? Being fairly anti-TDD myself it'd be good to keep this factoid in my pocket.
But he also has said it can be over-done.
Which is not surprising, because everything that can be done can be over-done.
One has to break the block of being afraid of failure - we all fail at various tasks. The important part is how we respond to this failures.