A P45 is the official document you receive when you leave employment (fired or not), it isn’t slang for anything though you may be threatened with a P45
> 1. Undocumented server setups with passwords saved in their own password manager and refusing to hand passwords and proccess after being fired.
That's as much a management issue as a developer one. There's no way the developer should have had sole power in the first place.
I mean, I get it. In a previous life I was "the IT guy" with absolute control over my domain. But I'd have hoped most organisations would have wised up nowadays.
>2. Hacking the servers after being fired and deleting the data
May I ask what happened with this?
For many companies step one would be to contact the feds, and then the former employee would awaken to the sound of their door being kicked in pursuant to a search warrant for all of their personal devices.
With the ubiquity of smartphone keyboards (I'm guessing), I've noticed a major trend toward zero punctuation, especially commas. You have to learn to just add them yourself, kind of like how a Javascript interpreter automatically inserts semicolons for you.
Your view might be from spending lots of time on HN and around engineers? I spend time with both, and I can see issues on both sides.
From the business side, here are examples I've seen:
- Have to use this technology, everything else is old, anachronistic, and unperformant
- System has to be scaled this way from the start (in startups, often, no it doesn't)
- Tension in how you trade off new features with clean code (there's a balance, and each environment requires a diff tradeoff)
- Building feature a certain way because it's easier for them, while ignoring what's appropriate for the customer/user
- Unwillingness or inability to explain technical topics to non-technical audience
- Making decisions solely on technical appropriateness, rather than broader appropriateness for the company (say, availability of other engineers to work on it)
There's lots on the managerial and business side too, but I'll save that for another thread.
P.S. A favorite quote of mine from Chinua Achebe (old proverb): Until the lions have their own historians, the history of the hunt will always glorify the hunter.
Any group we spend our time around will show itself in a good light. Even more so when we are a member of that group.
It can go both ways. I have seen bad management and I have seen bad engineers. "Bad" meaning hard to work with in this context. Usually the bad behavior I see from engineers is arguing pedantically every little point, not doing the paperwork, unilaterally deciding a feature should be implemented differently just because it is easier for them even though it hurts the product or business. Stuff like that.
I had a boss once who conjectured that when you point a finger, there are three pointed back at yourself. I often come in to "rescue" projects after an initial developer or team, and more often than not I find just as many mistakes on the management side. For example - if the developer(s) have set up the production environment using their own personal AWS account, or set up DNS in their own name, yes, they screwed up, but that's the company's IP that management has failed to secure. Problems go both ways.
If developers did that against original requests, that's a huge problem and the dev is at fault.
If, as I've sometimes seen, the dev asks for credentials, and a founder doesn't do it, or continually ignores the requests, but pushes for 'get it live', falling back to personal credentials (with reimbursement or using a company card) is a not-unusual fallback.
If, after it's done, requests for transfer to a 'company account' are not made, again, dev at fault. If requests are made, but not granted, owner's fault.
I've seen multiple scenarios happen, and they've gone in all directions.
We operate in a completely unregulated environment, where anyone can hang out their shingle, calling themselves a software developer. For that matter, even our CS programs are not really training people for careers as software developers. Thus, there is a huge spectrum of training, experience, and talent in what constitutes software development. But, what I've witnessed is that as the "software is eating the world" mentality has taken off, in many companies responsibility for everything about the software has been delegated downward (shit rolls downhill) to developers who are not product managers, not security experts, not database experts, not really anything except <$lang> developers and then the company is surprised when in the absence of support and resources, they resort to just get it done techniques.
I have interacted with off-shore development teams from a specific country 3 times now. I'll say the country later.
Every time the development team could not grasp what was required. You literally had to exchange 20 emails with them for each specific point. Of course, this just increased the length of time for scope and in all cases furthered the time of the project.
Each stage of the application was over engineered to infinity. Spaghetti code everywhere and nonsensical functions, callbacks, literally everything was what the hell was the developer thinking.
Of course it just about worked. They had to ship something, but it was slow. The UI was painted into a corner, in some cases doing the wrong thing literally crashed the browser because of an infinity loop or took too much memory.
Some apps had about a billion dependencies and therefore could never be secure. I'm not kidding either, it's like the developer was a plumber instead of actually knowing how to code the simplest of things.
There was no way to ever extend it to build atop newer features or have any sort of roadmap for user requests.
In every single time, management outsourced and took the bid from the lowest priced company. How to solve the problem? Start from scratch with a competent local company with an actual design and development process.
Want to know the best bit? One company I know of, who spent $6 million dollars on a project with an Indian company. An in-house developer took 3 months as a side project and rebuilt it from scratch. It ended up being the code from there on in.
I have NIH syndrome due to seeing these issues pop-up time and time again. In my career I've seen well over $15-20m being wasted in projects due to management being completely incompetent and thinking sitting on the phone with a dev team will ensure success.
Yes, exactly. The problem is that for many companies that decide to outsource, the motivating factor is cost savings. "Why pay $80-100/hr for an Indian engineer when I can pay $20?"
And then six months down the road, "why are all our systems so shoddy?" "Why are our development cycles so long?"
As a consultant, I've seen this pattern so many times it's insane. And depressing... and for better or worse, lucrative.
Paying more doesn't guarantee this. Lots of new developers want those top rates and deliver the same sub standard quality. On the other end, expensive consultants can be highly ineffective.
An HR manager once said each hire is a compromise in some way because no two candidates are alike.
One key in hiring remote is to take some extra time to get to know the candidates via video calls to create a connection and better determine what their strengths and weaknesses are, and get the conversation to a point where the compromise is acknowledged and you can talk about their ability to learn what they don't know and examples of that.
How effectively a developer can learn and apply new knowledge is they main thing I look for. Learning while you work is the new norm, but hiring is not always setup that way.
To work with many offshore firms, the “specs” part is a nightmare. The specs might as well be code because common sense isn’t generally so common. For example, sending a forgot password email: actual question: “Should the email go to the email address in the user’s record?” Multiply that by layers of “project managers” and over and over, that means that $35 per hour costs 3 times as much yet yielding a quality level that wasn’t $105 per hour worth.
I've worked with tremendously good Indian engineers as well. But in most cases they were already in the U.S. on some kind of visa, permanent residents or citizens.
I have had good experiences with outsourcing in India itself as well, there are some serious teams there too. But there were some bad cases as well.
Money is definitely an indicator of quality, expensive might not mean good but cheap almost always means they're not top talent.
Telstra, Australia's largest telecommunications provider did something similar many years ago. They had to spent X times more and hire locals to fix the code.
Your company chose the lowest priced company and was surprised when the quality of the work wasn't great. Because this isn't just unique to just India. This happens everywhere. To counteract this story. I worked at Apple where they used offshore engineers from India and the quality of the work was excellent.
You're just suggesting management should follow a waterfall PM structure.
We're supposed to get incomplete specs, it's the only way everyone can end up happy. It doesn't help pointing fingers at an ephemeral 'management' for not knowing exactly how an app should work up front.
That's par for the course when going for the cheapest bid, quality be damned, be it a local company or not. It's just that no local company in a richer country can compete on price, so the cheapest ones went away when globalization got going.
Most companies know one can't hire the cheapest job applicant, they try (more or less successfully) to vet them, yet somehow outsourcing companies are exempt. One wonders how much these managers actually want the project to succeed.
> In every single time, management outsourced and took the bid from the lowest priced company.
What was the initial bid of the Indian company that ended up costing $6 million dollars?
Stories like these make my blood boil. And to be fair it's not just Indian companies. There are plenty of EU/US based dev teams that consistently fail to deliver and the company still keeps paying them.
I wonder if management just can't deal with sunken costs or if someone is trying to steal money from their own company by making under-the-table deals with the development team.
I've had a couple of clients that dealt with "cheap" teams and wasted years of their life trying to get a product up and running. Taking them on felt like rescuing abused puppies from a shelter. Their eyes would light up every time they witnessed a working feature, no matter how simple it was.
5 years back , I wanted to buy a pair of good headphones. Ended up buying cheap headphones made in a country which broke in few months. After buying 3 cheap headphones I ended up buying quality one which was 4 times expensive and have never regretted that decision.
Sorry to hear about your ordeal. With my experience of working from both sides of the table, I can say for sure that you get what you pay for. Quality is not cheap. Companies in the west usually think that outsourcing to Asia and Eastern Europe would mean they can hire slave labor and pay peanuts for work that would cost an arm and a leg back home. As I said, you get what you pay for.
I am working with clients in the US, Europe and Australia. I know my limitations and never bid for work that me, or my team, can't deliver. This is why I have clients giving repeat work since last 7-8 years.
An issue that comes up is the without detailed specs, communication and project management skills, any development project will fall off the rails.
Many horror stories are caused by prematurely trying to go fast and making a bigger mess, not knowing how to design, specify, or oversee the building of software.
Overseas is as good as the garbage you can buy locally, but the problems get worse with the distance, time zone, and other things.
how to get these projects? how did the outsourcing company contacted you/management? where did the bidding happened?(upwork/freelancer/companies own bidding site)
I am amazed that low cost outsourcing companies are able to fetch millions of dollars worth of contracts while actual competent developers have hard time landing them.
I can empathise with the experience, and have seen many others go through the same.
Part of it is because many colleges(and by extension, firms) in India are focused on knowledge of frameworks and languages as a key indicator of skill and quality. Many, but not all. Which essentially means that, developers are hired cos they know X framework or Y language. When clients ask for devs, how do they choose? Based on skills. Now, when quality is measured not by simplicity but complexity, everything will be over engineered.
The workaround is to get a gang of people around a desk chatting with a line of code up. Its no longer a meeting, but you can slip in some "how we tracking on the deadlines" type questions.
Was working with a developer through Upwork who claimed to be from Japan. Was in fact from China. Upwork terminated their account without warning, and we owed the individual money. Was a legal and logistical pain in the ass. I guess this is a bad experience with Upwork as much as with a developer.
I came into a project where I quickly realized the 2 upwork developers was just 1 dude who decided he could double his pay. Management was asleep at the wheel.
It's hard to know how to apply the appropriate 'grain of salt' when reading things like this thread. I worked for a small (~40 person) start-up before where there was rampant religious discrimination and inappropriate workplace behavior by executives, even the head of HR who functioned more like a culture gatekeeper to enforce the particular overt religious cultural aspects of the founder.
When developers pushed back, they were called uncooperative, threatened with pay cuts or being fired, told they were not team players or were making too big a deal out of things. It was crazy!
In my experience, the times when management believe they are suffering from a problem developer are actually reflections of the management. There are exceptions like employee theft, issues with employees after they are terminated, and these things are often pretty black and white. But for all the other types of things that are more subjective about effort or cultural fit or finger pointing or tone or attitude or whatever, I tend to think most employees are absolutely not the problem, rather it is inept management and extremely poor culture mandates.
I disagree. Both sides can have issues, and it's not primarily the fault of "managers." You can see some issues that I list elsewhere in this thread.
The part I do agree with is that responsibility to address the issues often is in management.
I do wonder if every tribe thinks they're good, and it's the other side at fault? ... I think about this a lot in my media literacy work, where I explore the empathy gap:
Both sides can definitely have problems. But I think there are severe asymmetries at work, like what is chronicled in Moral Mazes. There is a big asymmetry about how managers and executives think the world is supposed to work for them, vs. what is a realistic compromise between complex teams that have to coordinate. Executive or management bad behavior can be hidden, papered over, politically rewritten, etc. etc., while executive opinions about the behavior of subordinates is often taken as unquestionably 'morally' right within the context of the morals and ethical systems that evolve inside a specific corporate hierarchy.
I think as an abstract sociology problem, there is every reason to believe the dynamics of the situation make it far more likely to be problems with management or executives, and that it ought to require extraordinary evidence to overturn that prior point of view and instead believe it's sincerely an attitude / effort / tone / culture fit sort of problem on behalf of employees.
This isn't really special to companies where employees are developers. It's just a general property of the phenomenon of a corporation, period.
We need a tool to convert a certain format to html, work flow required OCR and a few manual inspection items. An Indian outsourcing company took 2 months to finally setup the workflow. They'd be paid an initial fee, and every time we sent them a batch of file. They would stall on emails claiming national holidays. Memorable events included me needing to go through two levels of hierarchy before I was able to speak to a developer who knew how to change CSS or rather would change it.
This is when I realized that Indian society is fuck. Whatever modicum of knowledge one of them processes they jealously guard from their peers. It seems the kind of "better then tho" caste system is preserved in the knowledge economy. To an outside observer this knowledge was what a 18 kid with any motivation could learn.
I hired a Canadian (Also Indian) contractor to work with me to fully automate the system. We got done in 2 weeks and collected a substantial bonus. Our code is still in use a decade later.
I find a lot of developers seriously lack a professional mentality (I think I'm guilty of this in my youth though I made up for it in dedication and sheer hard work.)
Moving towards the business side I hired a lot of interns from commerce/marketing and they made my devs seem like little babies, it was shocking how capable, committed, team-oriented they were. It changed my view of things.
It's a matter of culture and perspective, and of course the fact that there is definitely such a thing as 'bad management' ... but Engs do have a tendency to think they know what's best for the product roadmap, and have really strong views about all sorts of things.
Some of this is good, in a way, but I really wish somehow the culture of development could be professionalized, both in terms of general approach to working at a company - but also in terms of the artisanal aspects of development itself.
It's important to set tone and expecations early, with smaller units it might work ... but as Eng teams get big, then they always end up reporting to Eng and not product, so it really depends on the culture that the VP Eng / CTO has established.
+ A general disregard for any activity that isn't specifically development. Like 'meetings'. Of course meetings can be overdone, but they can have a lot of value even if the topic being discussed at any moment isn't hyper-relevant to the developer himself. There's a commenter below who said he has a dev who'll bring in competitive offers if he's asked to go to more than two meetings a week for example. This dev has his 'teamwork' hat on upside down. Sometimes you need teamwork to focus on hyper specific issues. It may seem wasteful often it's not.
+ A general disregard for the talents and value of other groups. (Funniest example: 'ice cream day' at work and these devs cam to sit by us just as we were sitting down and a dev sneers: "Ugh, marketing". We just laughed.) Eng. talent is more classically academic, and yes, marketing is full of fluff, but good marketing, operations, finance is really hard. Basically an intellectual condescension that bleeds into a lot of things.
+ Failing to internalize that ultimately, they work for a business. Sometimes that means doing a lot of things an Eng would never do, like bolt-ons or weird add-ons to address specific customer needs. Cringing around metrics or optimizations that are ROI oriented and maybe not perfectly suited to their vision of what a 'good product' should be. This one can be a real problem in terms of attitude ... because they can get rally angry and stuffy. It's almost an existential debate over who really 'owns' the product in a sense - the business, or the people 'making it'? It really bothers me sometimes the cynical take that many Engineers have in this area - because the presumption is that 'they know better' or 'it's their thing' but really it's not at all. Basically, their view of 'raison d'etre' is often upside down. It depends on the organization.
+ Engs without management experience have a disrespect for how hard management actually is ... more so than in other groups. Marketing specialists are generally not like that.
+ Getting caught up in ideological wars about architecture, or 'bike shedding' - we're all guilty of this, but it's funny how ridiculous and perverse this is when you step outside of it. We're 'building something' not making some kind of 'functional art'. As techies we all love 'new toys' so this one is more understandable.
+ On the business side, if I ask staffers to get something figured out, to give me a quick analysis, to make some slides for the Veep, if they are good, they'll nail it down and move forward. On the dev side, if they even move to it, I get a lot of academic prose as though they don't know the language of business.
It's almost as though it's a little existential: so many on the business side play on 'sports teams' etc. are are very extroverted and team oriented, confident, and natural communicators. Often devs are not. So there's almost a natural cultural clash as well.
You don't have to strongly convince or persuade team players. They don't have tidbits of antagonism, or 'special needs'. They show up early, bang stuff out, realize that the world is somewhat political, that nothing is perfect, that we have to bend for customers, we do 'what needs to be done'.
Edit: hugely generalizing here. Everyone and every team is different.
Re-reading it I make it seems like devs are this terrible bunch! Not at all, most of this is subtle, it's nuanced, it's not like we have gross dereliction, just some different patterns of culture and behaviour.
I think many of these issues are caused by a "silo" mentality. Decisions often flow from the business end through product before finally ending up as a story in the developers backlog.
How can the devs understand the business decisions and learn to make less academic slides if they are not exposed to the business?
I worked at a medium sized business where devs had lunch with sales/product/marketing and was treated as more than just coders. That has helped me a lot when it comes to the business side of work.
If you have problems with the developers in your company, it may be that the real problem is with the company culture.
Devs are unique but I would argue it's less of the dev mentality and more about how management and business can incorporate them as part of the decision-making process.
Granted technical folk are a special breed but being technical myself and having moved over to the business side of things, it's still equally important to think about motivation for devs.
To maintain engagement, I bring my technical guys with me to meetings where they can add value. And I always press about the value of meetings and what we're trying to get out of it.
"...You don't have to strongly convince or persuade team players. They don't have tidbits of antagonism, or 'special needs'.
Yeah, and this is exactly the kind of person that gets laid off first. You have to be a little bit of an asshole to survive. Have an "edge", even if it works against the company, so you are perceived as a "badass".
I think this can also depend a lot on whom you hire. If you make that a screening criterion, it’s not all that difficult to assemble an engineering team entirely of people who understand business goals, can communicate with non-technical types, and recognize the value of other fields and departments.
Your list resonates with me on all points. Sadly, it seems that due to scarcity in the market some engineers are acting like self entitled, spoiled babies. The arrogant/know-it-all streak on topics way outside their area is also pretty pervasive. It changes with age though. I was like this 10 years ago to some degree. You mellow out over the years.
I think that you make a lot of very good points. I have also seen self-entitled, arrogant developers stomping around like they own the place, not respecting the difficulties in different roles (management) or other disciplines. I've seen endless bike-shedding, and endless toy-chasing (at the direct expense of the business).
But I also think that there are some significant problems in what you've said.
You describe what looks like a siloed structure, where sales/marketing people are deciding on what to build, and then throwing it over the fence to the developers to just "get on with". Where are the fast iterations, looping frequently back to the customer, and involving the whole team in the process? Does a developer never have a good idea with regards to features? I think that if you want robots who do what exactly they're told, then you're going to end up with... a development staff of robots.
Meetings. Endless meetings. Agile, if done on a weekly cycle, gives you no fewer than seven mandatory meetings. I don't disagree that it's important to communicate, but the prevailing culture across the industry is absolutely towards superfluous meetings which involve too many people. And I think that's a big problem. Yes, developers need to understand that perhaps not all of a meeting will be relevant to them, but if they're not relevant to the meeting, then really they shouldn't be in it.
"Failing to internalize that ultimately, they work for a business." - I think that the above point on solied structures is relevant here, but I think that there is more also. It depends on the type of business, and I think that you're referring to B2B. But I have personally seen in the B2C case, with millions of users, the sales and marketing side - sometimes from different divisions - preference their own career objectives over the user's experience. "We sold this for a million dollars" "But there's spyware on the partner side sometimes" "Tough. Build the integration". So while I think that you're right when it comes to building a special-case for a particular customer who genuinely needs that special case, I think that there are also other cases here where it's not that simple.
A more minor point but when you say "as though they don't know the language of business", I think you're right, they don't know the language of business!
I find your sports team / jocks vs nerds analogy interesting, perhaps mostly to inform on your general perspective. Personally I would prefer a team of smart developers who care deeply about the product that they build, working hand-in-hand with the product team, designers, sales, and customer in short iterations where rather than deciding precisely what will be built up-front, the solution is instead found organically with valuable contributions from everyone.
But you're dead right on the 'new toys'. That practice is unforgivable.
I would say that many developers often sweat about minute technical details but completely ignore business goals. I'm involved in the local dev community and after meetups we often go for drinks. You almost never hear people talking about their company's successes, growth, strategy etc. It's all about the new hot tech they've recently had a chance to use. This mentality is reflected in the way they carry themselves and make development related decisions.
Well, if they are not implicated in the business side of things, I don't see how they could be interested in. For example in my case, we're just getting feature requests for the next version, with no indication of business goals.
I’m not a founder, but I think it is not about developers, but rather about personalities (read same things happen everywhere). So, for me the worst things I saw:
Pure incompetence mixed with arrogance
Bad temper - impossible to argue without getting yell at
Chronically ignoring mission and goals (read like doing things they like vs what is needed)
Slacking and lying about it
Lying in general (work, travel, etc)
Psychopathic beghaviours
So, in all those cases, I believe, the only way is to say thank you and let go.
I have worked in software for 20 years with numerous being very early stage ventures. I would say that most of the problems I’ve faced in software venture is with non-technical founders who, generally speaking, provide minimal value until product-market fit is achieved. This sounds like the kind of question I might have faced in those ventures. If it’s a software venture and the founder is not either a skilled designer, talented product manager, or a developer working very closely together, it’s very unlikely to succeed. Perhaps a better question is “Developers, what is the worst experience you have had with a non-technical founder?”
Our Android developer silently inserted cryptocurrency mining code into the new release, pushed the clean version to github, but submitted the infected version to Google Play.
After a few weeks Google caught that and banned our app. We lost thousands of customers and years of work and had to start over with a brand new app. Years later the infected app is still mining cryptocurrency because users ignore Google’s malware warning message and keep using the app.
PS: I should have said “our FORMER Android developer.”
Developer attitude towards spending money on software...
"Invented Here Syndrome" when it comes to the choice between writing 50 lines of code vs. pulling in 4mb of client side dependencies to use a giant 3rd party (yet Open Source and therefore Free!) library that incidentally offers a solution to the same problem, after about 50 lines of configuration.
vs.
"Not Invented Here Syndrome" for anything that involves paying money for anything. Such as that API that solves the exact problem that's blocking us from moving forward, offered by a company that does nothing but solve that problem for a living, because we might outgrow their Free Tier and therefore face potentially thousands of dollars of charges. Argued among half a dozen market-rate developers of a venture funded startup that could really do with having launched yesterday. Rather, let's pause to build our own version of that service first. Then build our product.
I tend to notice these things while working as a consultant, and thus something of a bystander in terms of being able to do anything about it.
This. Developers often have a blind side to their own cost and will happily spend a week or more of their time (i.e. a few k$ at market rate) to shave $300 from an AWS bill.
They should start a business. Then they’ll realize how valuable their time really is and that $100/mo won’t seem so bad. (Note: I’m an eng who used to enjoy reinventing the wheel.)
We had a developer who worked on one of our projects. After he left, it was a disaster. Our new developers discovered that the names and items he used were strange and not related to what it should do. So the devs needed to go through all codes, figure out what it's doing and rename the code. It took a lot of time...
