4 ms·

> (badly coded, developed by multiple programmers over the years, handles the same tasks in different ways, zero structure) Yeah, that's totally normal for a m

> (badly coded, developed by multiple programmers over the years, handles the same tasks in different ways, zero structure) Yeah, that's totally normal for a mature application. Better get used to it. > At this moment I'm slightly beginning to get crazy from the daily mails of users (read managers) for each application I have to maintain. Maybe not normal, but common. It's really up to you to manage your business relationships and teach people how to work with you. How well you learn to do so will largely determine your happiness with your career. > The sad thing is I have yet to receive a bug report on anything that I have coded myself... Don't get cocky now. It'll happen. > P.S. My salary is almost equal if not lower then that of a cashier at a supermarket. That's not normal. Even a first job should pay better. In summary: demand more money now, give up on the code quality crusade, and concentrate on learning to work with people.

jms_ 14y ago
That's a terrible attitude to encourage. Accepting the status-quo as a junior is a great way to encourage them to never improve or question the more debatable practices. Teaching juniors to care about software quality and software maintainability is hugely important in order to encourage an overall improvement within the software dev industry.
- quanticle 14y ago
  But at what cost? Yes, overall improvement in the software development industry is great, but it's certainly not worth adding to burdens of this particular overworked software engineer. He or she has enough trouble dealing with the situation as it is, without inviting additional conflict with management.
  - jms_ 14y ago
    The point I was trying to highlight is that time spent on wading through the current situation is time not spent thinking critically about the inherent problems of said situation. I'm not saying to down tools and get on the war path with management, but to rather try to balance accepting whatever you are told and never coming up for air, versus sitting back for a time to analyse the situation and identify potential improvements. Ultimately it comes down to the individual, and whether they want to be a cog in the wheel, or whether they are interested in both improving themselves and thereby improving their employer.
    - kamaal 14y ago
      >>Ultimately it comes down to the individual, and whether they want to be a cog in the wheel, or whether they are interested in both improving themselves and thereby improving their employer. Yes this is important, but I think if your employer is in mood to listen. The next immediate step for you must be to start fishing for a job outside. And there is a reason for that. Your time is worth doing something important which is rewarding to you and your employer(I mean both in terms of value and financially). Challenge the status quo and try to improve things, if you absolutely cannot(for reasons beyond your control) you must leave people to their state and move on.
- zxcvb 14y ago
  You're wrong. He should accept that where he works, there is no respect for quality, he should embrace that and continue supporting the application in the best way he can without worry about the quality. He should do all this whilst applying and interviewing at places that do care about quality. There's no point in trying to fight the tide at his current company. He needs good references after all.
- engtech 14y ago
  When I was junior I really thought that everything can be fixed. As I've gained more experience I've realized that maintaining a code base is like any relationship with conflict -- you have to pick your battles carefully or everything turns into a fight / falls apart.
- pcopley 14y ago
  Yes, but a junior developer's role in any company regardless of size is most definitely not to come in and say how they could do it better and the company should change their workflow.
  - jms_ 14y ago
    I totally agree, but the value that a junior developer can bring to the table is a pair of unbiased eyes. It's what I look for when new developers join any existing team I am on: what can they see that we can't. At some point in the growth of a human being, we are discouraged from continually asking "Why?" and from questioning things we see. This is largely a bad idea, so showing junior devs that they are in a position to ask questions and help lead everyone to a better solution is great!
    - bluesnowmonkey 14y ago
      > It's what I look for when new developers join any existing team I am on: what can they see that we can't. Based on my experience, it would be unrealistic for a junior developer to expect this perspective at a new job. More realistic: here are the things that need to be done for this business to survive; please do them. Maybe some leeway in how you approach the problem. If they wanted unbiased eyes, the job listing would have said consultant, not junior developer. Believe me, I hear what you're saying. I've tried it many times. For instance: "You don't check everything into source control? Oh my god, it's so basic, look how much better you guys could be doing your jobs!" Which, yeah, it would have been better. It also annoyed the people around me and destabilized the team, even as it improved the technology. Net loss for the company. Having made this mistake over and over, I want to help others avoid it. Junior developers, know that if you find success in your job, your most important contributions to the company will not have been code. You will not bring some great insight to the table that makes everything faster/better/cheaper and wins you everyone's respect. You earn respect and admiration by working hard (not smart, hard!) and helping the people around you. Look up from your text editor, go talk to people, find out what they're doing, help them succeed. That's where your focus should be as a junior. (Or as a senior, for that matter.) Helping others succeed. Questioning the status quo is a distraction and not as useful as you think, even if you're right and everyone else is wrong. Maybe especially if you're right.
- eswangren 14y ago
  Also realize that junior devs often lack the experience needed to distinguish good code from bad and when it Is appropriate to rewrite large parts of an existing application that currently meets the needs of its customers
SideburnsOfDoom 14y ago
demand more money now, concentrate on learning to work with people, but do not give up on code quality. Not entirely, anyway. You can't turn the whole app into a good one in any reasonable time, but when you fix a bug, take time to apply the boy scout rule ( http://www.informit.com/articles/article.aspx?p=1235624&seqNum=6 http://www.informit.com/articles/article.aspx?p=1235624&... ) Don't put that down as a separate task that your management can approve or deny, it's part of doing the job of coding properly. That way, at least the buggy parts of the app get better. You should not be focused only on your career when making coding and tech decisions, but look at it this way: in a year's time, you're in an interview for a job you really want. What are you going to say "I can read and maintain shitty code" or "I can make shitty code better"? Also consider: documenting your app's architecture (or lack of it) and conventions (or lack of them). Also consider: reading up on architecture, testing, refactoring and code quality. If nothing else, these will help you get your next, better job. Off the top of my head, try "Domain Driven Design" by Eric Evans, "Growing object-oriented software guided by tests", "Refactoring" By Martin Fowler, and on the last topic "Clean code" by Robert Martin and "Code Complete" by Steve McConnell Big ball of mud apps (http://www.laputan.org/mud/ http://www.laputan.org/mud/ ) may be common, but it doesn't have to be that way - you can learn some pitfalls to avoid
- molmalo 14y ago
  I don't think that money resolves everything (at least, normal sums of money, lol). If they are paying him the minimum, that means they don't value what he does. I guess that's the reason he has a lot of projects to handle... probably other developers have left for the same reasons. Reductio ad absurdum: If somebody offers me a full time job of sewer-cleaning, paying me 15k, i'd probably pass, because I value other things besides money. I want to enjoy what I do, and the market right now (at least for the dev community) gives me enough options to choose where I want to work. He'd probably learn A LOT more, somewhere else, working with other people, and where the company actually values him. Someone would think that the kind of people who hires devs in such conditions, having a high employee turnover, would start to value them a little more. Sadly, my experience knowing a few cases firsthand, is that they think "there's always someone else".

jms_ 14y ago

That's a terrible attitude to encourage. Accepting the status-quo as a junior is a great way to encourage them to never improve or question the more debatable practices. Teaching juniors to care about software quality and software maintainability is hugely important in order to encourage an overall improvement within the software dev industry.

quanticle 14y ago
But at what cost? Yes, overall improvement in the software development industry is great, but it's certainly not worth adding to burdens of this particular overworked software engineer. He or she has enough trouble dealing with the situation as it is, without inviting additional conflict with management.
- jms_ 14y ago
  The point I was trying to highlight is that time spent on wading through the current situation is time not spent thinking critically about the inherent problems of said situation. I'm not saying to down tools and get on the war path with management, but to rather try to balance accepting whatever you are told and never coming up for air, versus sitting back for a time to analyse the situation and identify potential improvements. Ultimately it comes down to the individual, and whether they want to be a cog in the wheel, or whether they are interested in both improving themselves and thereby improving their employer.
  - kamaal 14y ago
    >>Ultimately it comes down to the individual, and whether they want to be a cog in the wheel, or whether they are interested in both improving themselves and thereby improving their employer. Yes this is important, but I think if your employer is in mood to listen. The next immediate step for you must be to start fishing for a job outside. And there is a reason for that. Your time is worth doing something important which is rewarding to you and your employer(I mean both in terms of value and financially). Challenge the status quo and try to improve things, if you absolutely cannot(for reasons beyond your control) you must leave people to their state and move on.
zxcvb 14y ago
You're wrong. He should accept that where he works, there is no respect for quality, he should embrace that and continue supporting the application in the best way he can without worry about the quality. He should do all this whilst applying and interviewing at places that do care about quality. There's no point in trying to fight the tide at his current company. He needs good references after all.
engtech 14y ago
When I was junior I really thought that everything can be fixed. As I've gained more experience I've realized that maintaining a code base is like any relationship with conflict -- you have to pick your battles carefully or everything turns into a fight / falls apart.
pcopley 14y ago
Yes, but a junior developer's role in any company regardless of size is most definitely not to come in and say how they could do it better and the company should change their workflow.
- jms_ 14y ago
  I totally agree, but the value that a junior developer can bring to the table is a pair of unbiased eyes. It's what I look for when new developers join any existing team I am on: what can they see that we can't. At some point in the growth of a human being, we are discouraged from continually asking "Why?" and from questioning things we see. This is largely a bad idea, so showing junior devs that they are in a position to ask questions and help lead everyone to a better solution is great!
  - bluesnowmonkey 14y ago
    > It's what I look for when new developers join any existing team I am on: what can they see that we can't. Based on my experience, it would be unrealistic for a junior developer to expect this perspective at a new job. More realistic: here are the things that need to be done for this business to survive; please do them. Maybe some leeway in how you approach the problem. If they wanted unbiased eyes, the job listing would have said consultant, not junior developer. Believe me, I hear what you're saying. I've tried it many times. For instance: "You don't check everything into source control? Oh my god, it's so basic, look how much better you guys could be doing your jobs!" Which, yeah, it would have been better. It also annoyed the people around me and destabilized the team, even as it improved the technology. Net loss for the company. Having made this mistake over and over, I want to help others avoid it. Junior developers, know that if you find success in your job, your most important contributions to the company will not have been code. You will not bring some great insight to the table that makes everything faster/better/cheaper and wins you everyone's respect. You earn respect and admiration by working hard (not smart, hard!) and helping the people around you. Look up from your text editor, go talk to people, find out what they're doing, help them succeed. That's where your focus should be as a junior. (Or as a senior, for that matter.) Helping others succeed. Questioning the status quo is a distraction and not as useful as you think, even if you're right and everyone else is wrong. Maybe especially if you're right.
eswangren 14y ago
Also realize that junior devs often lack the experience needed to distinguish good code from bad and when it Is appropriate to rewrite large parts of an existing application that currently meets the needs of its customers

SideburnsOfDoom 14y ago

demand more money now, concentrate on learning to work with people, but do not give up on code quality. Not entirely, anyway. You can't turn the whole app into a good one in any reasonable time, but when you fix a bug, take time to apply the boy scout rule ( http://www.informit.com/articles/article.aspx?p=1235624&seqNum=6 http://www.informit.com/articles/article.aspx?p=1235624&... ) Don't put that down as a separate task that your management can approve or deny, it's part of doing the job of coding properly. That way, at least the buggy parts of the app get better. You should not be focused only on your career when making coding and tech decisions, but look at it this way: in a year's time, you're in an interview for a job you really want. What are you going to say "I can read and maintain shitty code" or "I can make shitty code better"? Also consider: documenting your app's architecture (or lack of it) and conventions (or lack of them). Also consider: reading up on architecture, testing, refactoring and code quality. If nothing else, these will help you get your next, better job. Off the top of my head, try "Domain Driven Design" by Eric Evans, "Growing object-oriented software guided by tests", "Refactoring" By Martin Fowler, and on the last topic "Clean code" by Robert Martin and "Code Complete" by Steve McConnell Big ball of mud apps (http://www.laputan.org/mud/ http://www.laputan.org/mud/ ) may be common, but it doesn't have to be that way - you can learn some pitfalls to avoid

molmalo 14y ago
I don't think that money resolves everything (at least, normal sums of money, lol). If they are paying him the minimum, that means they don't value what he does. I guess that's the reason he has a lot of projects to handle... probably other developers have left for the same reasons. Reductio ad absurdum: If somebody offers me a full time job of sewer-cleaning, paying me 15k, i'd probably pass, because I value other things besides money. I want to enjoy what I do, and the market right now (at least for the dev community) gives me enough options to choose where I want to work. He'd probably learn A LOT more, somewhere else, working with other people, and where the company actually values him. Someone would think that the kind of people who hires devs in such conditions, having a high employee turnover, would start to value them a little more. Sadly, my experience knowing a few cases firsthand, is that they think "there's always someone else".