I'm a bit confused here. My understanding was that feature X has property Y. Is there something I'm missing here which means this doesn't work in this case?
Much better to start from the assumption that you are the one that is wrong, rather than the other way round. If you're wrong, you'll learn something; if you were in fact right, you've now ...
But something I need to do. But what?
Provide your feedback in a "constructive way", and be done about it. Not your place to make decisions.
Mention something along the lines of
"It was good to get a chance to evaluate the product X. As I see it:
- Pros: 1, 2, 3
- Cons: 1, 2, 3, 4, 5, 6, 7, 8, 9, ......
As it is evident from the analysis ...
This of course could place the company under serious fire for invading
users' privacy when we get found out. In fact, as far as my country's
laws go, it not only illegal, it is unconstitutional.
You're being asked to break the law and do things that might land you in prison or otherwise in serious trouble.
This argument fell on my CEO's deaf ears, ...
You should be focused on a lifeboat for yourself
Someone promoted you to lead a project with just 5 days remaining which is an absolute disaster? With only 5 days, it seems that they should have chosen an interim leader from the team itself. Unless they informed you of all these problems ( mostly interns, Unity license issues, and the exceedingly high ...
In my experience bugs are a consequence of (in no particular order):
Poorly defined or constantly changing requirements.
Too much work for the amount of time provided, which leads to rushing, which leads to mistakes, and insufficient time to test and fix defects before release.
Lack of peer code reviews (may be related to point 2).
Insufficient QA ...
I agree with Richard that you failed the first question, but I think you failed it in the opposite way. My experience comes from working on government contracts, so this answer is influenced heavily by how those clients and contracts work. This may not apply outside of that.
In my opinion, the first question is asking how you will deal with a potential ...
Is that too much to ask?
Not at all, rather they should be providing you with the written offer, before you ask.
DO NOT, I repeat, do not resign until you have a signed and sealed contract / offer in your hands.
There can be many reasons why your former boss cannot show you the contract before you resign - and none of the reasons are reasonable. This is ...
Since your boss doesn't care that this is incredibly invasive, warn him that starting on Android Q, to be released later this year, Android will (finally) block apps from recording video and sound while not in the foreground. Therefore, it will be the same situation you have with iOS.
Of course it will take sometime until Android Q has a significant ...
Unfortunately maintenance is the rule when working in IT, very rarely are there new projects, and people get reassigned around projects regularly. And while the quality of the code you will have to maintain in your professional life will vary widely, they will never smell the same as a fresh 2-6 month old project.
However, there are things you can do to ...
I suggest you put the question up for discussion to the team. Present your concerns at the next team meeting and ask what they think about them.
Since they sound like valid concerns I would imagine you'll get support from the other developers.
Make sure the discussion stays professional and keep an opened mind. Focus on how using X affects the rest of the ...
How would you deal with such situation ?
After nicely comforting him, which you have already done, it's time to firmly tell them to deal with it. It is not an individual's code, but the company's. As a manager, you need the code to be as maintainable as possible by your team and new additions you make to the team in the future.
"code formatting is ...
Document everything, starting now. You will likely need it.
Do not start building this feature. Do not prioritize it, do not write tickets for it, do not task your team with anything to do with it.
If management wants to chastise you over dereliction of duty, allow them to do so, and simply ignore everything they say. Document these situations as well.
You are worrying about nothing. Software has bugs, that is inevitable, and everyone knows it. QA finds bugs, hopefully puts them into a bug tracking system, and you take one bug from the bug tracker, fix it, then the next one and so on until you are finished.
There is no need to mention where this bug comes from. Nobody cares. If someone asks you why there ...
Get it in writing. Save a copy of said confirmation away from company hardware.
Violating software and service licenses are the kind of thing that, if they are caught, can really screw over a company. They will want someone to blame and an unscrupulous windbag will end up deleting any emails on the company servers related to their 'request' and make you ...
Honestly, my reaction would be the following:
Bob, I appreciate the feedback, but as a team we've decided that we're using Black as our mandatory code formatting tool, and that decision is final. I understand it's not your personal preference, but I'm afraid that you're going to need to learn to work with it.
But if I wanted to engage in a discussion?
Tl;DR: Raising complaints is expensive. Leaving is cheap. The hunt to leave can be fun. There are lots of places for engineers to go. Companies do a lot of things to make people want to leave without realizing it, including saving $250 on IntelliJ by driving away a dev who cost 10K to recruit.
Here are my thoughts:
It is probably not just your software ...
No, this isn't typical in any workplace.
You have a successful website that you built - $6,000 per year in ad revenue is nice. That, plus your bug fixing ability, and the new software you're building from scratch, are certainly enough to find you a better paying job in a company where you can actually learn from professional developers. I'd recommend ...
I'm going to go against the grain here. I'm probably wrong based on all the other answers and I'm looking forward to learning something from your comments. I'm also in the USA.
I think this is no big deal and you shouldn't push back.
Your colleague is a developer for the retail site. He could easily be monitoring the transactions and you jumped out as a ...
If it's a one-time thing, do the testing. Your team needs you. QA is drowning. Take over some of their workload and stay in contact with them to make sure you do the job, and you do it well.
After having proven yourself as someone who can be relied on in a pinch, you can then tell your manager man do I hate manual testing, and maybe they'll keep that in ...
This guy should be your role model. Buy him lunch and pick his brain!
Seriously, though. There is no shame in learning from younger co-workers.
(most people start out as 1 year contracted temps)
Your company sounds pretty bad. It usually only takes 3 to 6 months to find out if someone is a good fit. Sometimes, it takes even less.
Don't blame the new ...
After two weeks, I can say with confidence that I clearly didn't create value for this company and the other developers that helped me could have done my job instead of spending time with me.
You will not create "net positive" value for the company for much longer than that (even when I hire senior developers I assume they aren't net positive for 6 months). ...
How can I handle the risk to the project presented by X?
To address this, I am going to use your own words:
it's evolving fast / unstable - on going to document some older code,
he found some base functionality had been removed, wouldn't compile in
newer versions, so took a couple of days to re-implement it
the other devs are clearly ...
It's acceptable for software engineers to job hop if they have better opportunities. The unanimous consent of your developer-employees is that your company is not a good opportunity. This is of little surprise, based on the feedback you receive, combined with your disregard for the same.
You are calling
"no promotion track",
"no feedback" and
"no payment ...
This is not an average software development job, and you're right on the mark in guessing in what ways it differs. A typical such job will generally:
Pay far more.
Be well organized with a clear structure of management and processes.
Have far less turn-over.
Not care if you're 5 minutes late, let alone if you reached the door on time but your desk 5 ...
There was a time when I would have said "Stick it out, give things a chance."
That was then and this is now.
I've been where you are. What the "senior" did is unacceptable. Pulling your commits is marginally justifiable, if he IMMEDIATELY issues his design plan document. Deleting your (presumably private) branches is not.
Get out of there. As soon as ...