New answers tagged

0

Since it's about the workplace I'll answer in the perspective of the Workplace and career. Technologies and framework always change in our domain. If you touch different technologies, you will get to the new one easier, that's how it will be perceived in the future. Furthermore the technologies you quote are quite common (Js, Ts, C#) some experience in it ...


3

Many companies are risk averse. They have a product that is making revenue. Even after paying teams of developers, they are still making money. As you put it, the company has two options. Continue doing maintenance on existing products. Do minimal maintenance, and work on new products. While 2 may have potential for a new revenue stream, it is not ...


14

From your comments you knew from 11am that the work was complete, yet the PM was unavailable until 3PM, and as such could have contacted the relevant people to alert them when they were available. That didn't happen. You did, however, contact another Project Manager. There are two faults here - firstly, you didn't inform the actual project manager. ...


2

One of the principles of Agile Software Development is that teams are self-organizing. This means that it is up to the teams to determine how much work they can achieve (with an appropriate level of confidence) and then how they will go about doing the work. Through experience, we've learned that pull-based systems are highly effective - people will pull ...


1

I'm going to disagree with the other answers telling you to not raise the issue and to stick it out. You have a field of interest, which is machine learning. You were brought into this company to work on a machine learning project. Your boss, who is on the machine learning team, is not your supervisor, who is the project lead for this other project you're ...


0

I pretty much agree with the other answers about sticking it out. I bet if you paid attention to those around you, you would see that they are not spending all their time on their favorite tasks. Also, for me at least, those infrastructure-type projects have become more important to me as I've gained experience. They make my "main" tasks much more pleasant, ...


10

Being rigid in what you want to learn vs not learn and what you want to work upon vs not work upon will not help you as an Intern to gather practical learning and work experience. Life doesn't always go the way we want it to. Even during regular job, you will many times end up getting (grunt) work/projects/assignments that you will not enjoy. Since you ...


5

I wouldn't bring it up. To me, as a co-op or intern, that fact that you say that you are learning is a good thing. The purpose of such work experiences is to learn and, well, get experience. It seems like you're being asked to do things within the realm of your education and competence and are getting the appropriate support from your company and colleagues ...


1

I've seen this a lot, both with government (which has an astonishing backlog of legacy code that badly needs to be rewritten) and with many large, older companies. You are young and needed a first job, so you were a good candidate. It can work out for you as long as you don't fall into what I like to call the "First Job Trap". I have observed that people ...


3

I'd like to challenge the premise of your question. Who is the expert on developing software? You or your boss? Your boss hired you because you are an expert, a professional. Automatic testing is part of your work. So act like a professional and implement automatic testing if you deem it necessary. Does your boss also decide on whether you click to move to ...


0

I would say in a healthy environment you can head what Julie in Austin answered, unfortunately, those kinds of workplaces are few and far between, but only you would know which one you are in. It takes being more conscious. What kind of language are they using? Are they making comments such as "oh you are not what we thought". If so, yeah, it's time to ...


6

“Trade-offs” are almost always required, but delivering crap is not. If you find yourself being asked to deliver garbage, consider walking away. Or, if the software concerns finance, information security, or health, make that run away. (Because when it fails, management will be looking for scapegoats.)


8

What you call "shortcuts" are really trade-offs, and they are inherent in any project, in any discipline, you will undertake. It is inescapable. There is an idiom in the engineering world (yes, I put this in a comment above): You can do it well, you can do it fast, or you can do cheap. In the best case, you get to pick 2, so the decision needs to be made on ...


6

Assuming your team lead is your direct manager, I would schedule 1-1 time with him to see how he defines success in your first year. In that conversation, you can bring up that you are eager to learn, have capacity to work on new projects and want to accomplish the goals that you have both defined and documented. This exercise will give you a window into ...


4

What actions to take: The first is to explain to your manager what cost the shortcut is likely to make to the company. Worst case the shortcut means endangering and possibly killing people. Most harmless case is that you fix the problem next week and no harm is done. Your manager needs to know what it is to make an educated decision. The next action is to ...


19

Yes, technical debt is a perfectly valid decision in many cases; just like taking out real debt is a valid business decision in many cases to advance the business goals. (We'll make $$$ if we had $ capital to invest in the business, so getting a loan for $ and paying $$ back still puts us ahead in the long run.) But in my opinion skipping automated tests is ...


21

Software development is about managing risk in unknown or uncertain environments while frequently doing novel work. Making tradeoffs about time, scope, and quality happen all the time. The important thing to do is to help stakeholders understand the impact of their decisions on the project. To me, responses of "quit the job" or "blow the whistle" would be ...


108

Yes, the real world is a lot different to what you are taught at university. When you work for a business, the job is to make a profit, not deliver software according to an idealised software development process. A lot of the time these things overlap, but not always. It is perfectly legitimate to "cut corners" from time to time. While you may lament that ...


10

Forget imposter syndrome. You're right that sometimes people think they aren't as good as others or don't belong, and are wrong to think that. But you have a more serious problem: you're not sure if your performance is good enough for your job, and have already received some unsolicited advice from your manager a few times. It's natural to conclude that ...


2

The difficulties of tasks vary a lot. It is very common that some of them take longer than others. Some tasks that seem to be hard are actually self-contained and actually can be finished very quickly. So do not compare yourself with your coworkers. You are facing different tasks. It is also not helpful to consider yourself as a victim of Imposter Syndrome....


11

Whether or not you're cut out to be a developer is unrelated to Imposter Syndrome. If other people think, and act, as though you are better than you believe yourself to be, that would be Imposter Syndrome. That said, no one went from completely inexperienced to a Rock Star in a day, month, week or year. No one is expecting you to be super-productive, never ...


3

Since then I've gotten involved in half a dozen projects, but haven't actually completed any of them Given you are just one year into your career, is the general expectation that you are supposed to complete the project individually, or is it to work as a team to get them done? Do not compare your situation with your peers, as different projects and teams ...


4

Make a backlog and ask for input on prioritizing it. It sounds like they need your help in knowing what needs doing, and you need their help knowing what is most important to them. This is fairly typical for an organization, although in larger organizations you probably wouldn't be so central to the process so soon. So first make a backlog. This is just a ...


4

There is a huge difference between knowing what you're doing in IT and knowing what your employer is doing in IT. Your question does not describe a lack of skill or knowledge in IT subjects, it points out a lack of expressed goals by your employer. "I was hired as an expert of the field and I should know what is my objective at work." This would be true ...


0

Couldn't you just have a direct exchange with the emitter, live or over the phone/web. This would help focus on the desired behaviour and the edge cases. Otherwise I feel like asking for too much detail can be a burden for both parties. I would assume that the non-technical side leave out the details for you to fill out assuming that you know what is best ...


0

As an alternative, ask if the meeting time can be changed past your gym time. If the meeting is an hour, leave work an hour earlier go to the gym and join the meeting back home.


1

To answer your specific question what you wrote is fine, but you know that. Were you asked something similar by a random stranger your answer would be perfectly acceptable. However, in my opinion there is a very different relationship between an employee and employer and answering this question in such a way can ruin or end the relationship. It comes down ...


4

You may be able to do this, but you really shouldn't If the work isn't scheduled and prioritised you will be messing up the product plan/roadmap. So then the project managers should re-plan and re-prioritise and you'll end up working on the products they want rather than the fun stuff. The company gets used to the idea that they can get free work from you....


3

Can I legally do it? I guess it depends on country, and in my case, also European laws, but have no idea if this is even regularized. You are right about this. Many jurisdictions/countries/workplaces can mandate that all overtime be paid overtime, while some others can strictly enforce that an employee work no longer than X hours per week. So, The best ...


7

Many places allow/encourage/expect unpaid overtime, some places discourage it (due to burn-out) or there may be regulation issues (such as mandatory breaks depending on hours worked) or even union issues. It can be worth talking to your manager/boss about this, but beware of potential downsides: They may object to you working on your desired tasks and ...


6

You have a product manager who is supposed to know what customers will pay for. And that’s what he writes in his spec. And you realise that there needs to be more in a spec to create a product that actually works. Things that customers assume “will just work”. The product manager can’t do that. So someone needs to do it who can. Similar with graphics ...


2

It may not be your best example, but your example highlights an important point. say that an API response has a field called "timeOfEvent". Our PM defined it like this timeOfEvent = Time at which event occurred. This is not helpful for us. Should it be USA date format or something else ? Is that just a date or do you want the exact time down to seconds ...


12

Most PMs/BAs seem to set the requirements well for stories where we have to develop UI, i.e. things you can see on a screen. But, for non-UI things like APIs, they either don't provide requirements or provide superficial requirements. I've a general observation that many non-tech people do not understand detailed nuisances of technical details. It seems to ...


14

So, what should I do to make PMs accountable and give us proper requirements ? The moment you or your coworkers see an unclear requirement immediately ask for clarification. If you see such 'timeOfEvent' field and it is unclear proceed to ask the sort of questions you wrote here (what format we want the time? should this be triggered on creation? etc.). ...


4

I think exactly what you wrote is polite, succinct, and honest. I've been working in salaried positions for a couple years now, and they are a huge trap for this kind of thing. You can simply say "I have other commitments and am not available outside of my current schedule." They really shouldn't have a problem. Of course, every company is different. As ...


1

You have already answered your own question: Joe gets paid for every feature he completes rather than an hourly rate. It is my impression that Joe tries to get as many features done as possible, oftentimes skimping on documentation/code quality in the process. Switch Joe to an hourly contract and see what happens. If he is any good, his quality will ...


-3

Yes you're being unreasonable. As long as it's not life or death you should pass the code because management only care about money, and technical debt is not something they can understand. I've written shitty code because I've been given deadlines which don't allow enough time to do a good job and as a contractor I'm not paid to do overtime. If I was able to ...


Top 50 recent answers are included