Dude, I'm going to lay it out to you for real. I'm sure that no one else here has laid THE TRUTH out for you.
This is a shitty, terrible industry.
No one can properly estimate projects, its impossible. Businesses need the projects finished anyway though, so the entire fucking industry is built on abusive practices to bridge the gap between impossible fairy-tale schedules and the reality of building something immensely complicated where the time to completion was estimated by people that didn't really understand it in the first place.
Scrum and the "sprint" is a recipe for burnout. Employers demand far more than they should, the default attitude in the industry with regard to failure is blame and judgement, overtime is damn near mandatory, no one can effectively rate the work of any other individual unless there are obvious shortcomings, so bullshit impressions are used in place of any sound rating system. If you doubt this is true, look up example implementations for elevator models. We don't even have a sound consensus for how to properly write simple shit.
I've personally worked somewhere where my first week-long sprint included 5 things and one of the 5 things wound up taking at least 2 man years of development time split among a team of around 10 people. I wound up getting laid off from that position because no one had any idea of how difficult what was being asked for actually was.
There is no good advice other than do whatever little bullshit you can to make yourself look good and others look bad.
- Superficially refactor recently written code that doesn't need it whenever you have spare time and have a reason to work with it. This creates a ton of changes in your git repo, makes you look really good for doing minimal work, and your co-workers have to figure out how the new code works. which slows them down. The fact that you re-wrote it at all is a micro-aggression that says they're incompetent to anyone supervising. When you do this, there's a good chance your co-workers will just grumble about it quietly and not bother raising the issue. You'd be amazed how much a good refactor can throw someone off even on code they originally wrote. If they do raise the issue, just stick to your guns. Their code was harder to read, you had to re-write it to make it easier to understand. That kind of narrative will serve you well as you build the perception that you're superior to those around you. Hostile refactorings are an extremely common aggressive action in programming circles.
- Inflate the time for tasks you're likely to wind up with while undercutting time for tasks your co-workers will want to work with at scrum meetings. Scrum is a battle, and if you're not treating it as a battle, its because you're losing. If you think your co-worker has a vague understanding of the task, that's when you can really go for the throat.
- Do zero future prep for any work item unless its explicitly mandated that you do it in your current task. If called out on it "You knew we were going to have to add this eventually" stick to your guns and explain that its not how scrum works. Preparing for things in the future might be sane and reasonable engineering, but its not going to help you at all in today's cut-throat software industry. If you had some future task figured out in your head, and you add all the hooks needed to do it to your code and document it nicely, you will get exactly zero credit for having done that and the person who eventually implements it will look good. Perceptions are all relative to your peers, when they look good, you must necessarily look bad.
- Use the shortest variable names you can get away with. First, it artificially makes your code look "clean" (seriously, test this out. Greatly shortening identifier names instantly gives your code superficial cleanliness), which is impressive to the vast majority of even experienced programmers. More importantly it makes your code harder to actually understand, so your co-workers will be less likely to be able to easily work with it (it can prevent hostile refactors). This will make you look really good whenever someone else is assigned to work on something with you. Use cnt instead of num-selected-positions or total-upgraded-widgets. If someone calls you out on it, say that what the variable does is "obvious" due to the context. This is *always* true in code, you can always figure out what something is from the context no matter how badly named. If they didn't get it from the context its because they just aren't as smart as you are. If they continue to press you on it, they'll look like they're struggling at best, and trouble-makers at worst.
- Always code at the lowest level of abstraction you can without making your code seem out of place. If you're in a team that doesn't use polymorphism, you shouldn't use it either. If your team uses for statements rather than higher order functions, use for statements as well. Using those higher level abstractions will make your code easier to modify, read, and re-use and all of those things will make it easier for your co-workers to work with your code - reducing your perceived value. The only reason to use a higher level abstraction is if you know you can get away with it and if you're sure that your team will struggle with understanding it - like if you introduce a logic programming library to people that have never had any experience with logic programming.
- Avoid any kind of solo project. Software is always perceived to have taken too long to complete. The bigger the group you can work with the more you can "game" the process.
- Master any techniques you can that involve optimizing your code for performance, and use them liberally. It gives you an excuse to write bad code, but since its fast code, you are completely covered for having written it.
- If you're in OO land and you have the luxury of just creating crazy abstractions to do simple things for Christ sake do it. Be the guy that writes 15 classes to model an elevator. Every noun is an object, every verb can be an object too. Seek out and find those "tutorials" that show you how to write your code to be "modular". OO is a god damn fairy tale come true for anyone that wants to get ahead at their company.
- Use non-standard documentation if you can to keep yourself from getting confused. Don't write what you're doing down in comments in the code, comments should always just say shit that is easily apparent from reading the code, instead keep a word document or something separate from the code itself where you document everything, store it in some document repo maintained by your business intelligence people. No one will ever find it there, and it will be your own private cheat-sheet for working through the hell you've created.
So, I'm writing all that mostly tongue in cheek right? Right? Except that I've seen this shit done over and over again, especially hostile refactorings and shortened identifier names. I'm sure most everyone in the industry for more than a year or two has seen that.
I think some people shit all over their co-workers on accident, like they started learning from someone that used identifiers like "cnt" and started to see that kind of shit as "normal". Maybe those people aren't particularly driven as well, so they keep using low level abstractions everywhere, and maybe because of these inadvertent hostile actions, they thrive. They create home field advantages in the areas in which they work unintentionally, and that keeps others from appearing to do well there because others have to shift through the muck that's been written.
But I think that some people literally do that kind of shit as a form of hostile action. Some people really are psychopaths. Some people will cozy up to the boss and talk shit in complete confidence while doing a lot of what's on that list above... and you will never beat those people. Never in a million years. Those guys will be executives one day, you know the type, you meet them as middle managers hear that they used to be programmers and ask them about programming and they tell you that its been a long time and they don't really do it any more, they're doing something else now... as if they don't really have the skills, never developed the skills, instead developed other skills...
And of course if you're the boss and the guy kisses your ass constantly and you're not too impressed with his work (but you don't think he's really being hostile, no... people don't do that) but you have a minor management position that someone has to fill, hey why not? You like the guy after all. Will help the team too since they won't have to read his code anymore. Everybody wins.
I originally decided to respond to this to talk about how software engineers should really think about unionizing, but I guess I'm far afield from that. Everyone's convinced they're a 1 in 100 developer, so I'd be wasting my time advocating that anyway.
Never forget that stimulant abuse is common in our industry. Always remember that you might not have the whole story. I would never encourage someone to use drugs, but if you have trouble focusing... and we all do... talking to your doctor is always an option. Just don't mention it at work because people will use it against you.
I've worked at places where I was absolutely convinced that management and half the dev staff was all high on cocaine all the time. The older I get the more convinced I am that not only is this the case, but that its happening pretty much everywhere. People aren't averaging 60+ hour work weeks in times of crisis with a family and marriage and other responsibilities without help. I've worked at shops where we had people pulling upwards of 80 hours for two weeks. I've had at least one person above me tell me that they're on high doses of amphetamines with a wink-wink nudge-nudge.
This is a shitty, terrible industry.
No one can properly estimate projects, its impossible. Businesses need the projects finished anyway though, so the entire fucking industry is built on abusive practices to bridge the gap between impossible fairy-tale schedules and the reality of building something immensely complicated where the time to completion was estimated by people that didn't really understand it in the first place.
Scrum and the "sprint" is a recipe for burnout. Employers demand far more than they should, the default attitude in the industry with regard to failure is blame and judgement, overtime is damn near mandatory, no one can effectively rate the work of any other individual unless there are obvious shortcomings, so bullshit impressions are used in place of any sound rating system. If you doubt this is true, look up example implementations for elevator models. We don't even have a sound consensus for how to properly write simple shit.
I've personally worked somewhere where my first week-long sprint included 5 things and one of the 5 things wound up taking at least 2 man years of development time split among a team of around 10 people. I wound up getting laid off from that position because no one had any idea of how difficult what was being asked for actually was.
There is no good advice other than do whatever little bullshit you can to make yourself look good and others look bad.
- Superficially refactor recently written code that doesn't need it whenever you have spare time and have a reason to work with it. This creates a ton of changes in your git repo, makes you look really good for doing minimal work, and your co-workers have to figure out how the new code works. which slows them down. The fact that you re-wrote it at all is a micro-aggression that says they're incompetent to anyone supervising. When you do this, there's a good chance your co-workers will just grumble about it quietly and not bother raising the issue. You'd be amazed how much a good refactor can throw someone off even on code they originally wrote. If they do raise the issue, just stick to your guns. Their code was harder to read, you had to re-write it to make it easier to understand. That kind of narrative will serve you well as you build the perception that you're superior to those around you. Hostile refactorings are an extremely common aggressive action in programming circles.
- Inflate the time for tasks you're likely to wind up with while undercutting time for tasks your co-workers will want to work with at scrum meetings. Scrum is a battle, and if you're not treating it as a battle, its because you're losing. If you think your co-worker has a vague understanding of the task, that's when you can really go for the throat.
- Do zero future prep for any work item unless its explicitly mandated that you do it in your current task. If called out on it "You knew we were going to have to add this eventually" stick to your guns and explain that its not how scrum works. Preparing for things in the future might be sane and reasonable engineering, but its not going to help you at all in today's cut-throat software industry. If you had some future task figured out in your head, and you add all the hooks needed to do it to your code and document it nicely, you will get exactly zero credit for having done that and the person who eventually implements it will look good. Perceptions are all relative to your peers, when they look good, you must necessarily look bad.
- Use the shortest variable names you can get away with. First, it artificially makes your code look "clean" (seriously, test this out. Greatly shortening identifier names instantly gives your code superficial cleanliness), which is impressive to the vast majority of even experienced programmers. More importantly it makes your code harder to actually understand, so your co-workers will be less likely to be able to easily work with it (it can prevent hostile refactors). This will make you look really good whenever someone else is assigned to work on something with you. Use cnt instead of num-selected-positions or total-upgraded-widgets. If someone calls you out on it, say that what the variable does is "obvious" due to the context. This is *always* true in code, you can always figure out what something is from the context no matter how badly named. If they didn't get it from the context its because they just aren't as smart as you are. If they continue to press you on it, they'll look like they're struggling at best, and trouble-makers at worst.
- Always code at the lowest level of abstraction you can without making your code seem out of place. If you're in a team that doesn't use polymorphism, you shouldn't use it either. If your team uses for statements rather than higher order functions, use for statements as well. Using those higher level abstractions will make your code easier to modify, read, and re-use and all of those things will make it easier for your co-workers to work with your code - reducing your perceived value. The only reason to use a higher level abstraction is if you know you can get away with it and if you're sure that your team will struggle with understanding it - like if you introduce a logic programming library to people that have never had any experience with logic programming.
- Avoid any kind of solo project. Software is always perceived to have taken too long to complete. The bigger the group you can work with the more you can "game" the process.
- Master any techniques you can that involve optimizing your code for performance, and use them liberally. It gives you an excuse to write bad code, but since its fast code, you are completely covered for having written it.
- If you're in OO land and you have the luxury of just creating crazy abstractions to do simple things for Christ sake do it. Be the guy that writes 15 classes to model an elevator. Every noun is an object, every verb can be an object too. Seek out and find those "tutorials" that show you how to write your code to be "modular". OO is a god damn fairy tale come true for anyone that wants to get ahead at their company.
- Use non-standard documentation if you can to keep yourself from getting confused. Don't write what you're doing down in comments in the code, comments should always just say shit that is easily apparent from reading the code, instead keep a word document or something separate from the code itself where you document everything, store it in some document repo maintained by your business intelligence people. No one will ever find it there, and it will be your own private cheat-sheet for working through the hell you've created.
So, I'm writing all that mostly tongue in cheek right? Right? Except that I've seen this shit done over and over again, especially hostile refactorings and shortened identifier names. I'm sure most everyone in the industry for more than a year or two has seen that.
I think some people shit all over their co-workers on accident, like they started learning from someone that used identifiers like "cnt" and started to see that kind of shit as "normal". Maybe those people aren't particularly driven as well, so they keep using low level abstractions everywhere, and maybe because of these inadvertent hostile actions, they thrive. They create home field advantages in the areas in which they work unintentionally, and that keeps others from appearing to do well there because others have to shift through the muck that's been written.
But I think that some people literally do that kind of shit as a form of hostile action. Some people really are psychopaths. Some people will cozy up to the boss and talk shit in complete confidence while doing a lot of what's on that list above... and you will never beat those people. Never in a million years. Those guys will be executives one day, you know the type, you meet them as middle managers hear that they used to be programmers and ask them about programming and they tell you that its been a long time and they don't really do it any more, they're doing something else now... as if they don't really have the skills, never developed the skills, instead developed other skills...
And of course if you're the boss and the guy kisses your ass constantly and you're not too impressed with his work (but you don't think he's really being hostile, no... people don't do that) but you have a minor management position that someone has to fill, hey why not? You like the guy after all. Will help the team too since they won't have to read his code anymore. Everybody wins.
I originally decided to respond to this to talk about how software engineers should really think about unionizing, but I guess I'm far afield from that. Everyone's convinced they're a 1 in 100 developer, so I'd be wasting my time advocating that anyway.
Never forget that stimulant abuse is common in our industry. Always remember that you might not have the whole story. I would never encourage someone to use drugs, but if you have trouble focusing... and we all do... talking to your doctor is always an option. Just don't mention it at work because people will use it against you.
I've worked at places where I was absolutely convinced that management and half the dev staff was all high on cocaine all the time. The older I get the more convinced I am that not only is this the case, but that its happening pretty much everywhere. People aren't averaging 60+ hour work weeks in times of crisis with a family and marriage and other responsibilities without help. I've worked at shops where we had people pulling upwards of 80 hours for two weeks. I've had at least one person above me tell me that they're on high doses of amphetamines with a wink-wink nudge-nudge.
