Interesting that you'd think my system to be inferior to someone else's system. But we've all seen version control systems fail equally big. My system hasn't failed big. We can say yet, as we always can. And there are backups of course. So in the event that everything vanishes, I've got backups for months and can re-instate a working project in a matter of hours from nothing. But again, my system allows a developer to break one file at a time. So if they make a change, and a file blows up, then we just grab the old file from last week, or last month, or yesterday.
And like I also said, there are aspects of my system that protect the developer from majorly screwing up the live system while mid-development.
But more importantly, my current platform has been in production for over 15 clients and over 50 projects for over 5 years, and it hasn't had any such drama. I think that history stands for itself. And I've seen the history on version controlled companies -- it sucks.
But hey, you might not be open-minded enough to see that perhaps someone has built something better than your current tools. But if you are, I'd be happy to discuss it with you in detail, and prove to you that you would indeed feel very comfortable working in my system. It's odd that you'd already think you wouldn't, having no idea how it works.
The whole point of the justice system isn't to punish people for making mistakes. It's to punish them for intentionally making mistakes as a deterant.
In this case, the problem wasn't the spill -- it's certainly not something that they did intentionally, and hence they needn't be discouraged from spilling again. The problem is that they didn't follow through with the obvious safety procedure of screaming "fire!" and "get out of the way!" and "the oil is coming!".
Not screaming -- or not screaming soon enough loud enough -- is something that they did intentionally. Had they done so, they could have saved people from trouble.
So no, this isn't the start of companies being forced to take responsibility for their actions. This is the start of companies being forced to switch into life-saving mode following a dramatic event.
This isn't stopping drivers from hitting pedestrians. This is stopping drivers who, having hit a pedenstrian, from running away instead of helping that injured pedestrian. (sorry, you just gotta do the car analogy)
Oh, if you're talking about billion-dollar companies, then hey, for every Rolling Stones, there are ten thousand garage bands.
Ditch the multi-billion dollar companies. My small company can make me between $100'000 and $300'000 per year. That's not winning any records. And I can't buy an island. But over the last 10 years, it's never made me any less -- and that's through a mighty recession.
I'm certainly not saying that everyone can create a successful company. I am saying that by 40, with experience in an industry, those who can't don't deserve to expect better treatment than a young-hire. There are 40 year-olds who simply aren't spectacular. That's fine. But that's why they are passed up for younger workers who haven't yet proven that they aren't going to be spectacular.
So no, I don't believe your argument applies to the OP. If you're looking for a good six-figure annual income, and you're willing to risk your time money and effort to figure out how, and you're willing to get screwed over a few dozen times along the way, then you'll make it. It's hard. It's difficult. And it's straight-forward.
No, that's exactly my point! At that point, they've improved enough to the point where they can fly on their own. So I want them to take the helm, grab the wheel, hold the reigns.
The guy that you describe so succinctly, I want him! And because he knows how to talk to customers, I want him to take a project from start to finish. Do the work that he likes, delegate the work that he doesn't. I want him to call new clients and talk to them like the expert that he is. And because he can take calculated risks, I want him to choose those risks! I trust his calculations, so I want him to lay his own money on the line (along with mine) so he has skin in the game, and I want him to make his calculations and go for it.
If he doesn't do all of that, I want him to never ask for a raise, I want him to never expect any new kind of challenges, I want him to never complain that his job is boring. I want him to never cut back on the amount of time he spends.
I know someone told you that, but you might want to actually read the law. Because I have. And, as it turns out, it's perfectly legal for me to make that the first question of the interview, and it's perfectly legal for me to base my hiring on the answer, and it's perfectly legal for me to discriminate based on age.
The law, to which you are refering, states that it is "sometimes" illegal to discriminate based on age.
So read the law yourself. And then if you don't believe that I'm allowed to discriminate based on age, post that law here and I'll show you how to read it.
And in general, start reading laws for yourself. They are public for a reason.
Oh, by the way, I'm also allowed to discriminate by religion, gender, and I'm not sure but I think by physical disability as well.
Yeah, this isn't the discussion about version control. But I'll counter with the following: everyone who's used version control has accidentally reverted to an earlier version without intention. Either losing newer code the same way you describe the situation, or reverting a live project. Version control also comes with other threats. Mass-migrating a full project with databases, codebases, files, etc, from version to version can be problematic. Aside from general conflicts, database schemata can't just be migrated the way files can. So at some point, the whole "push it live now" day goes wrong half the time. So we're not looking for a solution with no problems, we're looking for a solution with fewer problems.
I'm telling you that, having designed my platform from scratch, I did so to avoid all of the problems that version control has. I designed it to avoid any sort of sudden mass push effort. I designed it to avoid having a non-live version of the project that may or not work with the live data. I designed it to avoid having any sort of conflict resolution. I designed it to avoid the need for any documentation. I designed it to avoid having multiple developers working in the same file at the same time. I designed it to avoid having any issues with working on the live site.
I'm telling you that I've designed a system that doesn't do what version control does. Instead, it solves the same root problems that version control tries to solve. A totally different solution to the exact same problems.
More importantly, I'm telling you, straight up, that I don't have problems. What does it take for you to tell me to solve problems that I don't have? I didn't ask for your opinion. If you've got problems, and version control solves all of them and adds none, then that's great for you. Otherwise, maybe you should look into my solution.
Hey, if that's what you believe, and if it works for you, then by all means enjoy your life. For me, this is what's worked and continues to work for me. I have a company, I work for clients that I like, I make good money, I have a house, I have a car, and I'm very happy. I attribute my happiness, in large part, to the perspective I've been discussing herein. I think it'd work for others too. It needn't work for you.
But like I said elsewhere, the original post asked for my opinion, and I gave it. I didn't ask for yours, I'm not looking for any help, I'm happy with things the way they are. I hope you enjoy your life as much as I enjoy mine. There are certainly multiple ways to be happy.
But what does it take for a person like yourself to tell me that I need help, when I'm perfectly happy? I took psychology 101, sounds like you're projecting.
Adult conversation? I think you've misunderstood. I responded to someone else's post. I gave my opinion, and a summary of what I do and why I do it. My perspective of how I run my company. The conversation wasn't with you.
Then you engaged me with the words "What utter bollocks.". And you expect me to speak to you with any respect? I didn't ask for your opinion, and I'm not interested in your idea of what I should do with my company -- that's why I don't work for you.
If you desire an adult conversation with me, you'll need to make me believe that it's worth my while. At this point, I have no reason to believe that my life would be improved by conversing with you at all.
You're talking about expert skills in which they lack confidence?
If those skills are expert, then that 40 year old should be willing to bet their money on it. That means not getting paid until the client pays. That means letting the client delay payment in order to get more work out of the client.
If those skills are so expert, then I don't need to supervise that employee. I can expect them to do the work properly, and they can supervise themselves.
If those skills are so expert, then I don't need to tell that employee how to use them. That employee can just take a project, and apply their skills to complete it without any assistance from me.
If those skills are so expert, then I don't need to teach them to someone else. That employee can teach someone else for me.
If that employee applies their own skills, gets paid directly from the use of those skillls, teaches other employees those skills, and supervises their own work, then they are self-managed partners, team leaders, and that's awesome.
On the other hand, if they don't take the financial risk on their own skills, and they aren't interested in doing things my way which conflicts with their way, and they won't teach junior employees their skills, and I need to supervise them, then they aren't worth very much to me because there's a maximum amount of profit that I can extract from them. In that case, the only way for me to profit on them is to sell projects that fit their skills precisely.
That makes then inflexible, in a market that's anything but. That makes them less valuable to me than the lowly peon who'll do things any way that I say.
My stance is very simple. If I hire someone older than 40 (and for this conversation, let's say I'm paying them an amount that a 40-year old needs to live on, and let's also say that I'm not sitting over him the way I would a 14 year old), I expect them to learn what I'm looking for very quickly. More so, I expect them to bring a wealth of experience in some area with which they're familiar -- after all, they've done something for a decade; whatever it was, I can profit from it.
And very quickly (many months, or a couple of years) I want them to not need my supervision at all. As adults, I expect them to make decisions and be able to trust their work. So I want them to bet on themselves. I want to pay them from profits. That means they don't get paid until the client pays (if the client pays). That lets us do interesting things like double-down on client projects, instead of forcing clients to pay on-time. It reduces the necesarry cash-flow (since I don't need to pay the employee on a schedule) which in turns grow the total amount of profit.
I'd then like that 40 year old to have the opportunity to bring in new clients. It needn't be a coordinated affair. But when they are at a baseball game, and the guy in the next seat asks what he does for a living, the enswer needn't be "I work in a cubicle at a programming company". It can be "I build software that does X". The latter inspires a conversation where that random stranger can become a prospect. That's the only way that I get clients now. That's how it works.
I've said elsewhere, but my ideal programming team has always been two senior developers working on a given project, with one or multiple junior developers as assistants for minor tasks able to be verified upon completion. "Manager" isn't to the exclusion of everything else.
Wow, you've insulted my products, my services, my goats, my opinions, and my actions, you've stated a fact about my business, and you've done it all anonymously. I don't know what to say. You're not making any sense. Why do I need a 51 year old senio developer for this conversation? I'm very confused.
You've read it all backwards. First off, I build $50'000 projects. Many of those projects grow to $300'000 projects. I do it without version control because I've built something that works better than version control -- allowing me and a few outhor developers to work directly on live systems without the risks typical of doing so. It's cool, and it's got nothing to do with version control.
Thanks for the insult, by the way.
As for the employees as serfs, and rewards and risks, you've said what I've said. Employees don't deserve the rewards if they don't take the risks. That's what you said. That's your first complete sentence.
That's all I said. Oh, and that when it comes to hiring 40 year-olds, an employer wants that employee to take the risks. An employer expects an experienced employee to want to take those risks.
That's what I hire employees to do. I hire them to grow and to eventually take their own risks.
A) I believe any given project (whole or incremental but single client, single delivery) is best served by two senior programmers working together, with one junior programmer as an assistant (more if the project has many sub-tasks). The idea is to have that junior programmer see the ropes, then slowly take on internal tasks on their own, until that junior programmer can act as the second senior programmer on a small project. Then, of course, becoming a senior programmer in time.
B) the term "team leader" is a term I extracted from another post. In that team of programmers above, the twe senior programmers are team leaders together. The junior programmers are their assistants to handle the more individuated tasks that come with a project -- the tasks that can be easily verified upon completion.
C) two seniors and one junior means that two thirds of the programmers are "team leads". Let's call it half since many projects can manage multiple juniors, and not every junior sticks around.
D) Of course, this "senior programmer" or "team lead" as we're calling it isn't the end of the line. The next step changes nothing about the job, but has that senior programmer take money from client cheques, instead of on a schedule -- so they have the financial risk. Obviously the reward becomes higher, as they are effectively "invested".
E) Then that "invested" programmer starts to acquire new clients -- in any of the ways that happens. And from those clients, they get to extract a much higher pay. This makes them "partners" in the business -- bringing in new business, and being responsible for doing or delegating the work within the company.
That's how a good company grows. By taking juniors, training them, and relying on them, letting them prove themselves, letting thehm grow the company. At that point, there effectively become multiple partners each acting as owners, they simply don't manage the corporation backend (accounting, human resources, etc). At that point, if they want to become a different department with a different focus, or break off into an affiliate, or whatever, that's up to them.
Incidentally, you may notice, law firms tend to work this way. "Making partner" is exactly what that means.
Heh, bit of a sidebar. But no, I don't like version control. It's bitten me in the ass so many times in so many ways that I gave up on it a decade ago, back in the CVS days. More recently, I took another stab at it with mercurial. Only to learn that half of the problems still exist, and that it doesn't do what I'd want version control to do at all -- track version changes.
So in my mind, it may have a few benefits when a dozen programmers work on an unorganized codebase, but it's horrible in situations where either there are few programmers, or when the codebase is structured logically (by feature, instead of abstraction layer).
This is a much longer conversation, that I can detail quite well. Let me know if you really care.
I guess I meant it directly, or as it applied to the situation, or, ah screw it, my grade 11 english teacher would be so upset. Mr. Simmons, is that you?
I didn't say that. What I said was that every business owner's purpose in business is to increase the amount of benefit each employee brings to the company. The moment that stagnates, that employee isn't worthwhile anymore.
But again, if you don't like the way your employer manages the company, manage your own any way you please.
Don't get angry at me for my confirming that I do the same thing the original post described.
You either do or you do not put your own money on the line. You can be a manager, you can be a programmer, you can be both, or you can be neither. The only question is this: when the client doesn't pay the invoice, do you still take money. That's it.
If you take money in that situation, then it was a hand-out. You took money out of your boss's pocket. That means you get paid first. That means you've taken zero financial risk on that project.
If you're 40, and you aren't taking the risk on your own work, then you're not worth any more than you ever were. In which case, I'm better off with a younger, harder-working employee who doesn't think he's worth much yet, who's still trying to prove himself, and who may, one day, actually take some risk of his own.
But if you're still taking orders, and taking money, then you aren't an adult. You're a dependent child. And you're worth exactly that much.
So grow up, and be accountable for your own actions. Or stay where you are, and quit complaining when you aren't any better than someone else. Because that's precisely what "better" means in this industry. It means you can take reigns and be responsible for your own mess.
I didn't say any of that. You're looking at intention and motivation, and probably a dozen other subjective and interpreted metrics. I don't care about any of those. I care about what actually happens. Yes out of 10 programmers only one will get it. And sure, it'll be management's "fault" most of the time. But it doesn't matter why. It only matters that.
I'm not looking for any random manager. Nor for any random programmer. I'm looking for the programmer that fits the management. I choose to base the programmers on the management instead of the other way around because I pay the management more than I pay the programmers, and the management is more loyal to me than are the programmers.
That's my choice. As a great comedian is known to say: they're my rules, I make them up.
Again, and as always, if the programmer doesn't like my rules, they are certainly capable of leaving and making their own rules. That's EXACTLY what I did.
I didn't like the way my employer divided projects. So I found a new employer. I didn't like the way that employer programmed their platform (no database). They wouldn't let me improve things. So I found a new employer. I didn't like the way that employer didn't let me know what was happening with the clients. So I started my own company and did things my own way.
No surprise, I lost one not-so-great employee who didn't like my rigidity with procedures (I hate version control). I lost another perfectly decent employee who didn't like my lack of interest in major platform upgrades (ironically, I didn't see that one coming from my employee experience). And I lost a really good partner because he didn't like my focus on tedious efforts over challenging efforts.
Again, if you want something done your way, you get to risk your own money on it. If you expect to get paid whether or not the client pays the invoice, then you just plain don't get to have the last word on anything. It's that simple. And when you work for someone whose entire life, family, car, house, pension, vacation, and retirement are all wrapped up in the success of the business, then you get to have no word on anything. You get to advise, you get to suggest, and you get to get over-ruled by someone willing to put everything on the line while you have nothing to lose.
Again, risk it all, and you'll get to decide what happens -- whether you like it or not. But you don't get to say how someone else risks their money. You aren't risking yours. That makes you a dependent. That makes you a child. That makes you gutless -- and I mean that literally, not offensively. That's all fine. But that's the truth. If it's what you want, more power to you. Some people don't want that. Don't bother asking those people for money.
The tech world is different. Different because it's based not on hard labour, but on making clear and correct decisions. Be it programming, analysis, or project management, in this world the real effort isn't in the work; it's in deciding what work should be done.
The actual work -- the long hours, the youth-oriented efforts discussed in the post -- is the blue-collar work. It's the low-wage, low-responsibilty, low-risk work of this industry. Of course it's best-suited to the young.
It's not age discrimination to say that any 40 year-old in this industry should know how to make decisions without being told what to do. It's not age discrimination to say that any 40 year-old in this industry should be ready and willing to take responsibility for their own decisions. It's not age discrimination to say that any 40 year-old in this industry should want to be accountable for their work and take the financial risks associated with that work.
What makes this industry different is that the lowly bottom-rung intern programmer has a direct path through project management into senior management right from the start. Unlike most other industry, there's no "management track". Everyone's in the management track. That intern should become a team programmer, then a senior programmer, then a team leader, then a senior team leader, then a team manager, then a senior manager, and then should be acquiring and selling to their own (or partially own) clients.
So given a 40 year-old, with more than 5 years of experience in the industry, who isn't in a management role, it's not age discrimination to say that the person isn't interested in becoming anything more than they already are. And given a employee who isn't interested in moving up, it's not age discrimination to prefer an employee who does.
This industry is all about those willing to spend an absurd amount of time focusing on a ridiculously specific task, and those willing to risk their finances on the success and viability of their own decisions. If you aren't willing to work through the night routinely, and you aren't willing to put your own money on the line, then there are plenty of other industries for you.
Believe it or not, this industry is not about four decades of being told what to do. It's about 2 years of being told, 2 years of being taught, 2 years of being encouraged, and if you don't get it by then, 2 years of finding someone else. As an employer, I'm not interested in the 40 year-old that I need to supervise. I'm not interested in risking my money on the reliability of that 40 year-old. And I'm not interested in paying such an employee more than I would to someone I'm expecting to grow.
So, as always, if you don't like the employment options available to you, start your own business and do it however you like.
Start a business that only hires 40 year-olds. That's perfectly fine too. It can be the first question in your interview. It can be the only question in your interview. Make it work your way. Stop complaining when others do it their way. That's exactly the point. Either make decisions, or do what you're told. And sometimes, what you're told is that you simply aren't good enough. So when that time comes, stand up and prove otherwise with your own business. Some of us have.
SO, they didn't destroy the documents, and now they're upset about it. Maybe, just maybe, they need to do a better job of destroying sensitive documents.
About six years ago, even before my company grew from just me, to me plus more, I removed the reply all button. Clients e-mail me every hour, and they often copy one of their colleagues. But they never want me to reply to those colleagues. One accidental click of the nearly-identical looking and nearly-identically labelled button adjacent to the reply button, and I'd get yelled at by a client, with every right to do so.
Don't need security solutions, add-ons, or weird shit. Just right-click customize toolbar, and remove the offensive button. That's enough. It can stay in the right-click menu, and it can remain a keyboard shortcut. You aren't stopping people from e-mailing with multiple recipients. You're just making them realize that they shouldn't.
Oh yeah, and the company policy that says no employee should ever ever ever reply to more than a single client address at a time. You know, 'cause a reply is to the author. You can't "reply" to another recipient. That's not english.
You can't put up a sign that says "only a few people allowed beyond this point". And you can't put up a sign that says "very little loitering accepted". So you put up signs that read "no access beyond this point" and "no loitering", and then you simply don't enforce it for the first few people.
If this company has a reduced staff, or wants to ensure that large problems don't happen during sensitive times, then they might want the freeze. And saying that there will be a freeze is the way to do that. But calling them and saying "hey, I know there's a freeze, but I'd really appreciate this patch when it's convenient." won't likely be met with a solid "no, screw you, we're in a freeze".
Ice is usually still a little wet. Not every molecule freezes at the same instant.
Look at it as an opportunity for you to be nice. They said "we'd really like to ease the harsh environment of christmas IT", and you can optionally say "I'll help you out by not patching for a while". It's an opt-out instead of an opt-in scenario, but it's the same.
You're complaining about the default, not the final. And you can override the default with a phone call. Don't sweat it.
and you needn't quote what I said one paragraph above. I know what I said, and it's available at a click. I haven't quoted you, I'm assuming that you can play the matching-game from grade 1 with point/counter-point arguments.
I hardly think that ethnicity is the definition of diversity in that sentence. I'd have understood diverse applications of ruby, or diverse techniques of ruby.
And the original post didn't say that it was being cancelled because people criticized. It said it was being cancelled because sponsors were being pressured by social networks.
Slashdot Mirror
Oh certainly, but that's not a criminal offense. That just a professional obligation.
Interesting that you'd think my system to be inferior to someone else's system. But we've all seen version control systems fail equally big. My system hasn't failed big. We can say yet, as we always can. And there are backups of course. So in the event that everything vanishes, I've got backups for months and can re-instate a working project in a matter of hours from nothing. But again, my system allows a developer to break one file at a time. So if they make a change, and a file blows up, then we just grab the old file from last week, or last month, or yesterday.
And like I also said, there are aspects of my system that protect the developer from majorly screwing up the live system while mid-development.
But more importantly, my current platform has been in production for over 15 clients and over 50 projects for over 5 years, and it hasn't had any such drama. I think that history stands for itself. And I've seen the history on version controlled companies -- it sucks.
But hey, you might not be open-minded enough to see that perhaps someone has built something better than your current tools. But if you are, I'd be happy to discuss it with you in detail, and prove to you that you would indeed feel very comfortable working in my system. It's odd that you'd already think you wouldn't, having no idea how it works.
The whole point of the justice system isn't to punish people for making mistakes. It's to punish them for intentionally making mistakes as a deterant.
In this case, the problem wasn't the spill -- it's certainly not something that they did intentionally, and hence they needn't be discouraged from spilling again. The problem is that they didn't follow through with the obvious safety procedure of screaming "fire!" and "get out of the way!" and "the oil is coming!".
Not screaming -- or not screaming soon enough loud enough -- is something that they did intentionally. Had they done so, they could have saved people from trouble.
So no, this isn't the start of companies being forced to take responsibility for their actions. This is the start of companies being forced to switch into life-saving mode following a dramatic event.
This isn't stopping drivers from hitting pedestrians. This is stopping drivers who, having hit a pedenstrian, from running away instead of helping that injured pedestrian. (sorry, you just gotta do the car analogy)
Oh, if you're talking about billion-dollar companies, then hey, for every Rolling Stones, there are ten thousand garage bands.
Ditch the multi-billion dollar companies. My small company can make me between $100'000 and $300'000 per year. That's not winning any records. And I can't buy an island. But over the last 10 years, it's never made me any less -- and that's through a mighty recession.
I'm certainly not saying that everyone can create a successful company. I am saying that by 40, with experience in an industry, those who can't don't deserve to expect better treatment than a young-hire. There are 40 year-olds who simply aren't spectacular. That's fine. But that's why they are passed up for younger workers who haven't yet proven that they aren't going to be spectacular.
So no, I don't believe your argument applies to the OP. If you're looking for a good six-figure annual income, and you're willing to risk your time money and effort to figure out how, and you're willing to get screwed over a few dozen times along the way, then you'll make it. It's hard. It's difficult. And it's straight-forward.
No, that's exactly my point! At that point, they've improved enough to the point where they can fly on their own. So I want them to take the helm, grab the wheel, hold the reigns.
The guy that you describe so succinctly, I want him! And because he knows how to talk to customers, I want him to take a project from start to finish. Do the work that he likes, delegate the work that he doesn't. I want him to call new clients and talk to them like the expert that he is. And because he can take calculated risks, I want him to choose those risks! I trust his calculations, so I want him to lay his own money on the line (along with mine) so he has skin in the game, and I want him to make his calculations and go for it.
If he doesn't do all of that, I want him to never ask for a raise, I want him to never expect any new kind of challenges, I want him to never complain that his job is boring. I want him to never cut back on the amount of time he spends.
I know someone told you that, but you might want to actually read the law. Because I have. And, as it turns out, it's perfectly legal for me to make that the first question of the interview, and it's perfectly legal for me to base my hiring on the answer, and it's perfectly legal for me to discriminate based on age.
The law, to which you are refering, states that it is "sometimes" illegal to discriminate based on age.
So read the law yourself. And then if you don't believe that I'm allowed to discriminate based on age, post that law here and I'll show you how to read it.
And in general, start reading laws for yourself. They are public for a reason.
Oh, by the way, I'm also allowed to discriminate by religion, gender, and I'm not sure but I think by physical disability as well.
Yeah, this isn't the discussion about version control. But I'll counter with the following: everyone who's used version control has accidentally reverted to an earlier version without intention. Either losing newer code the same way you describe the situation, or reverting a live project. Version control also comes with other threats. Mass-migrating a full project with databases, codebases, files, etc, from version to version can be problematic. Aside from general conflicts, database schemata can't just be migrated the way files can. So at some point, the whole "push it live now" day goes wrong half the time. So we're not looking for a solution with no problems, we're looking for a solution with fewer problems.
I'm telling you that, having designed my platform from scratch, I did so to avoid all of the problems that version control has. I designed it to avoid any sort of sudden mass push effort. I designed it to avoid having a non-live version of the project that may or not work with the live data. I designed it to avoid having any sort of conflict resolution. I designed it to avoid the need for any documentation. I designed it to avoid having multiple developers working in the same file at the same time. I designed it to avoid having any issues with working on the live site.
I'm telling you that I've designed a system that doesn't do what version control does. Instead, it solves the same root problems that version control tries to solve. A totally different solution to the exact same problems.
More importantly, I'm telling you, straight up, that I don't have problems. What does it take for you to tell me to solve problems that I don't have? I didn't ask for your opinion. If you've got problems, and version control solves all of them and adds none, then that's great for you. Otherwise, maybe you should look into my solution.
Hey, if that's what you believe, and if it works for you, then by all means enjoy your life. For me, this is what's worked and continues to work for me. I have a company, I work for clients that I like, I make good money, I have a house, I have a car, and I'm very happy. I attribute my happiness, in large part, to the perspective I've been discussing herein. I think it'd work for others too. It needn't work for you.
But like I said elsewhere, the original post asked for my opinion, and I gave it. I didn't ask for yours, I'm not looking for any help, I'm happy with things the way they are. I hope you enjoy your life as much as I enjoy mine. There are certainly multiple ways to be happy.
But what does it take for a person like yourself to tell me that I need help, when I'm perfectly happy? I took psychology 101, sounds like you're projecting.
Adult conversation? I think you've misunderstood. I responded to someone else's post. I gave my opinion, and a summary of what I do and why I do it. My perspective of how I run my company. The conversation wasn't with you.
Then you engaged me with the words "What utter bollocks.". And you expect me to speak to you with any respect? I didn't ask for your opinion, and I'm not interested in your idea of what I should do with my company -- that's why I don't work for you.
If you desire an adult conversation with me, you'll need to make me believe that it's worth my while. At this point, I have no reason to believe that my life would be improved by conversing with you at all.
You're talking about expert skills in which they lack confidence?
If those skills are expert, then that 40 year old should be willing to bet their money on it. That means not getting paid until the client pays. That means letting the client delay payment in order to get more work out of the client.
If those skills are so expert, then I don't need to supervise that employee. I can expect them to do the work properly, and they can supervise themselves.
If those skills are so expert, then I don't need to tell that employee how to use them. That employee can just take a project, and apply their skills to complete it without any assistance from me.
If those skills are so expert, then I don't need to teach them to someone else. That employee can teach someone else for me.
If that employee applies their own skills, gets paid directly from the use of those skillls, teaches other employees those skills, and supervises their own work, then they are self-managed partners, team leaders, and that's awesome.
On the other hand, if they don't take the financial risk on their own skills, and they aren't interested in doing things my way which conflicts with their way, and they won't teach junior employees their skills, and I need to supervise them, then they aren't worth very much to me because there's a maximum amount of profit that I can extract from them. In that case, the only way for me to profit on them is to sell projects that fit their skills precisely.
That makes then inflexible, in a market that's anything but. That makes them less valuable to me than the lowly peon who'll do things any way that I say.
My stance is very simple. If I hire someone older than 40 (and for this conversation, let's say I'm paying them an amount that a 40-year old needs to live on, and let's also say that I'm not sitting over him the way I would a 14 year old), I expect them to learn what I'm looking for very quickly. More so, I expect them to bring a wealth of experience in some area with which they're familiar -- after all, they've done something for a decade; whatever it was, I can profit from it.
And very quickly (many months, or a couple of years) I want them to not need my supervision at all. As adults, I expect them to make decisions and be able to trust their work. So I want them to bet on themselves. I want to pay them from profits. That means they don't get paid until the client pays (if the client pays). That lets us do interesting things like double-down on client projects, instead of forcing clients to pay on-time. It reduces the necesarry cash-flow (since I don't need to pay the employee on a schedule) which in turns grow the total amount of profit.
I'd then like that 40 year old to have the opportunity to bring in new clients. It needn't be a coordinated affair. But when they are at a baseball game, and the guy in the next seat asks what he does for a living, the enswer needn't be "I work in a cubicle at a programming company". It can be "I build software that does X". The latter inspires a conversation where that random stranger can become a prospect. That's the only way that I get clients now. That's how it works.
I've said elsewhere, but my ideal programming team has always been two senior developers working on a given project, with one or multiple junior developers as assistants for minor tasks able to be verified upon completion. "Manager" isn't to the exclusion of everything else.
Wow, you've insulted my products, my services, my goats, my opinions, and my actions, you've stated a fact about my business, and you've done it all anonymously. I don't know what to say. You're not making any sense. Why do I need a 51 year old senio developer for this conversation? I'm very confused.
You've read it all backwards. First off, I build $50'000 projects. Many of those projects grow to $300'000 projects. I do it without version control because I've built something that works better than version control -- allowing me and a few outhor developers to work directly on live systems without the risks typical of doing so. It's cool, and it's got nothing to do with version control.
Thanks for the insult, by the way.
As for the employees as serfs, and rewards and risks, you've said what I've said. Employees don't deserve the rewards if they don't take the risks. That's what you said. That's your first complete sentence.
That's all I said. Oh, and that when it comes to hiring 40 year-olds, an employer wants that employee to take the risks. An employer expects an experienced employee to want to take those risks.
That's what I hire employees to do. I hire them to grow and to eventually take their own risks.
A) I believe any given project (whole or incremental but single client, single delivery) is best served by two senior programmers working together, with one junior programmer as an assistant (more if the project has many sub-tasks). The idea is to have that junior programmer see the ropes, then slowly take on internal tasks on their own, until that junior programmer can act as the second senior programmer on a small project. Then, of course, becoming a senior programmer in time.
B) the term "team leader" is a term I extracted from another post. In that team of programmers above, the twe senior programmers are team leaders together. The junior programmers are their assistants to handle the more individuated tasks that come with a project -- the tasks that can be easily verified upon completion.
C) two seniors and one junior means that two thirds of the programmers are "team leads". Let's call it half since many projects can manage multiple juniors, and not every junior sticks around.
D) Of course, this "senior programmer" or "team lead" as we're calling it isn't the end of the line. The next step changes nothing about the job, but has that senior programmer take money from client cheques, instead of on a schedule -- so they have the financial risk. Obviously the reward becomes higher, as they are effectively "invested".
E) Then that "invested" programmer starts to acquire new clients -- in any of the ways that happens. And from those clients, they get to extract a much higher pay. This makes them "partners" in the business -- bringing in new business, and being responsible for doing or delegating the work within the company.
That's how a good company grows. By taking juniors, training them, and relying on them, letting them prove themselves, letting thehm grow the company. At that point, there effectively become multiple partners each acting as owners, they simply don't manage the corporation backend (accounting, human resources, etc). At that point, if they want to become a different department with a different focus, or break off into an affiliate, or whatever, that's up to them.
Incidentally, you may notice, law firms tend to work this way. "Making partner" is exactly what that means.
Heh, bit of a sidebar. But no, I don't like version control. It's bitten me in the ass so many times in so many ways that I gave up on it a decade ago, back in the CVS days. More recently, I took another stab at it with mercurial. Only to learn that half of the problems still exist, and that it doesn't do what I'd want version control to do at all -- track version changes.
So in my mind, it may have a few benefits when a dozen programmers work on an unorganized codebase, but it's horrible in situations where either there are few programmers, or when the codebase is structured logically (by feature, instead of abstraction layer).
This is a much longer conversation, that I can detail quite well. Let me know if you really care.
The "literally" was figurative.
I guess I meant it directly, or as it applied to the situation, or, ah screw it, my grade 11 english teacher would be so upset. Mr. Simmons, is that you?
I didn't say that. What I said was that every business owner's purpose in business is to increase the amount of benefit each employee brings to the company. The moment that stagnates, that employee isn't worthwhile anymore.
But again, if you don't like the way your employer manages the company, manage your own any way you please.
Don't get angry at me for my confirming that I do the same thing the original post described.
You either do or you do not put your own money on the line. You can be a manager, you can be a programmer, you can be both, or you can be neither. The only question is this: when the client doesn't pay the invoice, do you still take money. That's it.
If you take money in that situation, then it was a hand-out. You took money out of your boss's pocket. That means you get paid first. That means you've taken zero financial risk on that project.
If you're 40, and you aren't taking the risk on your own work, then you're not worth any more than you ever were. In which case, I'm better off with a younger, harder-working employee who doesn't think he's worth much yet, who's still trying to prove himself, and who may, one day, actually take some risk of his own.
But if you're still taking orders, and taking money, then you aren't an adult. You're a dependent child. And you're worth exactly that much.
So grow up, and be accountable for your own actions. Or stay where you are, and quit complaining when you aren't any better than someone else. Because that's precisely what "better" means in this industry. It means you can take reigns and be responsible for your own mess.
I didn't say any of that. You're looking at intention and motivation, and probably a dozen other subjective and interpreted metrics. I don't care about any of those. I care about what actually happens. Yes out of 10 programmers only one will get it. And sure, it'll be management's "fault" most of the time. But it doesn't matter why. It only matters that.
I'm not looking for any random manager. Nor for any random programmer. I'm looking for the programmer that fits the management. I choose to base the programmers on the management instead of the other way around because I pay the management more than I pay the programmers, and the management is more loyal to me than are the programmers.
That's my choice. As a great comedian is known to say: they're my rules, I make them up.
Again, and as always, if the programmer doesn't like my rules, they are certainly capable of leaving and making their own rules. That's EXACTLY what I did.
I didn't like the way my employer divided projects. So I found a new employer. I didn't like the way that employer programmed their platform (no database). They wouldn't let me improve things. So I found a new employer. I didn't like the way that employer didn't let me know what was happening with the clients. So I started my own company and did things my own way.
No surprise, I lost one not-so-great employee who didn't like my rigidity with procedures (I hate version control). I lost another perfectly decent employee who didn't like my lack of interest in major platform upgrades (ironically, I didn't see that one coming from my employee experience). And I lost a really good partner because he didn't like my focus on tedious efforts over challenging efforts.
Again, if you want something done your way, you get to risk your own money on it. If you expect to get paid whether or not the client pays the invoice, then you just plain don't get to have the last word on anything. It's that simple. And when you work for someone whose entire life, family, car, house, pension, vacation, and retirement are all wrapped up in the success of the business, then you get to have no word on anything. You get to advise, you get to suggest, and you get to get over-ruled by someone willing to put everything on the line while you have nothing to lose.
Again, risk it all, and you'll get to decide what happens -- whether you like it or not. But you don't get to say how someone else risks their money. You aren't risking yours. That makes you a dependent. That makes you a child. That makes you gutless -- and I mean that literally, not offensively. That's all fine. But that's the truth. If it's what you want, more power to you. Some people don't want that. Don't bother asking those people for money.
The tech world is different. Different because it's based not on hard labour, but on making clear and correct decisions. Be it programming, analysis, or project management, in this world the real effort isn't in the work; it's in deciding what work should be done.
The actual work -- the long hours, the youth-oriented efforts discussed in the post -- is the blue-collar work. It's the low-wage, low-responsibilty, low-risk work of this industry. Of course it's best-suited to the young.
It's not age discrimination to say that any 40 year-old in this industry should know how to make decisions without being told what to do. It's not age discrimination to say that any 40 year-old in this industry should be ready and willing to take responsibility for their own decisions. It's not age discrimination to say that any 40 year-old in this industry should want to be accountable for their work and take the financial risks associated with that work.
What makes this industry different is that the lowly bottom-rung intern programmer has a direct path through project management into senior management right from the start. Unlike most other industry, there's no "management track". Everyone's in the management track. That intern should become a team programmer, then a senior programmer, then a team leader, then a senior team leader, then a team manager, then a senior manager, and then should be acquiring and selling to their own (or partially own) clients.
So given a 40 year-old, with more than 5 years of experience in the industry, who isn't in a management role, it's not age discrimination to say that the person isn't interested in becoming anything more than they already are. And given a employee who isn't interested in moving up, it's not age discrimination to prefer an employee who does.
This industry is all about those willing to spend an absurd amount of time focusing on a ridiculously specific task, and those willing to risk their finances on the success and viability of their own decisions. If you aren't willing to work through the night routinely, and you aren't willing to put your own money on the line, then there are plenty of other industries for you.
Believe it or not, this industry is not about four decades of being told what to do. It's about 2 years of being told, 2 years of being taught, 2 years of being encouraged, and if you don't get it by then, 2 years of finding someone else. As an employer, I'm not interested in the 40 year-old that I need to supervise. I'm not interested in risking my money on the reliability of that 40 year-old. And I'm not interested in paying such an employee more than I would to someone I'm expecting to grow.
So, as always, if you don't like the employment options available to you, start your own business and do it however you like.
Start a business that only hires 40 year-olds. That's perfectly fine too. It can be the first question in your interview. It can be the only question in your interview. Make it work your way. Stop complaining when others do it their way. That's exactly the point. Either make decisions, or do what you're told. And sometimes, what you're told is that you simply aren't good enough. So when that time comes, stand up and prove otherwise with your own business. Some of us have.
SO, they didn't destroy the documents, and now they're upset about it. Maybe, just maybe, they need to do a better job of destroying sensitive documents.
About six years ago, even before my company grew from just me, to me plus more, I removed the reply all button. Clients e-mail me every hour, and they often copy one of their colleagues. But they never want me to reply to those colleagues. One accidental click of the nearly-identical looking and nearly-identically labelled button adjacent to the reply button, and I'd get yelled at by a client, with every right to do so.
Don't need security solutions, add-ons, or weird shit. Just right-click customize toolbar, and remove the offensive button. That's enough. It can stay in the right-click menu, and it can remain a keyboard shortcut. You aren't stopping people from e-mailing with multiple recipients. You're just making them realize that they shouldn't.
Oh yeah, and the company policy that says no employee should ever ever ever reply to more than a single client address at a time. You know, 'cause a reply is to the author. You can't "reply" to another recipient. That's not english.
You can't put up a sign that says "only a few people allowed beyond this point". And you can't put up a sign that says "very little loitering accepted". So you put up signs that read "no access beyond this point" and "no loitering", and then you simply don't enforce it for the first few people.
If this company has a reduced staff, or wants to ensure that large problems don't happen during sensitive times, then they might want the freeze. And saying that there will be a freeze is the way to do that. But calling them and saying "hey, I know there's a freeze, but I'd really appreciate this patch when it's convenient." won't likely be met with a solid "no, screw you, we're in a freeze".
Ice is usually still a little wet. Not every molecule freezes at the same instant.
Look at it as an opportunity for you to be nice. They said "we'd really like to ease the harsh environment of christmas IT", and you can optionally say "I'll help you out by not patching for a while". It's an opt-out instead of an opt-in scenario, but it's the same.
You're complaining about the default, not the final. And you can override the default with a phone call. Don't sweat it.
and you needn't quote what I said one paragraph above. I know what I said, and it's available at a click. I haven't quoted you, I'm assuming that you can play the matching-game from grade 1 with point/counter-point arguments.
I hardly think that ethnicity is the definition of diversity in that sentence. I'd have understood diverse applications of ruby, or diverse techniques of ruby.
And the original post didn't say that it was being cancelled because people criticized. It said it was being cancelled because sponsors were being pressured by social networks.