Though the company was a total failure (CEO management nightmare), small companies do present more opportunities for growth and learning experience.

Ah, you're right there of course. We can definitely change and influence our environment, and we can influence how effectively products are delivered, but you cannot necessarily save a company from a bad executive.

It's irrelevant, however, for a company to demand "understand agile" if all they are hiring for is somebody to write code.[/quote]
I can see that. I think I read his post more about general improvement and not specifically about SDLC improvement.

[font=arial, verdana, tahoma, sans-serif][size=2]

Here is an example:
Dice Job Posting

What exactly is this company looking: a developer who understand the inside and out of Flex/Java and all its relevant technologies, or somebody who can manage projects and understand Scrum and Agile?

[/font][font=arial, verdana, tahoma, sans-serif][size=2]It's pretty clear they are looking for a software developer since they said:[/font]

* Some experience with Agile/SCRUM methodologies and principles: Continuous Integration, Maven, Unit Testing, Pair Programming[/quote]There is hardly an emphasis on Agile / SCRUM methodologies and it's clear they are not looking for a scrum master.

I take issue with the concept of Best Practice; the biggest issue I have is that many supposed practictioners or Best Practice have no understanding of WHY something is considered to be best. To use it correctly, you have to understand why a particular practice is considered to be the best, who by, and in what situation.

For example, globals are a brilliant way to solve a problem immediately, but they have implications, so to avoid cowboying, you should consider the implications of the use of globals. The same thing applies to singletons; in what situations are they likely to cause problems? What problems might they cause? What alternatives are there?

Not sure I agree with this. A lot of best practices are great for those who don't fully understand it and deviating from best practices is best left to those who understand the problem and why deviating from accepted practices is the right move to make. In your singleton example, the general understanding of singletons is that they are anti-patterns and it's best to not use them. That's not to say that someone who understands the problems with singletons cannot effectively use them when the situation is right. Globals also go against best practices, and while it's important for someone to understand why globals are a bad practice, they can gain immediate benefit to their code by following the best practice.

I think that the best antidote to the feeling that you are a cowboy yourself would be to adopt defensive programming.[/quote]
Which itself is a best practice!

The solution, which I have now learned to provide in future, is to provide a data access method along the lines of getPageSafeData() which performs all the page safe escaping for you. This way, next time I work with noobs, I can be sure my data isnt going to inject nasty things into their pages.[/quote]

I don't think that will necessarily help you. The bad programmers will likely not use your new safe getPageSafeData method and will pull out the data themselves. After all, they could have easily used the built in [color="#1C2837"]htmlspecialchars method to escape the data, but they didn't. Unless they have ego problems or are really bad programmers, I think a better approach is education. Point out why what they are doing is bad, and how they can prevent that in the future. There is a good article somewhere over why trying to write code to protect against bad developers is a bad thing, but I'm having trouble finding it right now.

[quote name='speciesUnknown' timestamp='1318387960' post='4871701']
I take issue with the concept of Best Practice; the biggest issue I have is that many supposed practictioners or Best Practice have no understanding of WHY something is considered to be best. To use it correctly, you have to understand why a particular practice is considered to be the best, who by, and in what situation.

For example, globals are a brilliant way to solve a problem immediately, but they have implications, so to avoid cowboying, you should consider the implications of the use of globals. The same thing applies to singletons; in what situations are they likely to cause problems? What problems might they cause? What alternatives are there?

Not sure I agree with this. A lot of best practices are great for those who don't fully understand it and deviating from best practices is best left to those who understand the problem and why deviating from accepted practices is the right move to make. In your singleton example, the general understanding of singletons is that they are anti-patterns and it's best to not use them. That's not to say that someone who understands the problems with singletons cannot effectively use them when the situation is right. Globals also go against best practices, and while it's important for someone to understand why globals are a bad practice, they can gain immediate benefit to their code by following the best practice.


[/quote]
Just to clarify, it is the concept of Best Practice which I have issues with. Most people I have asked about this define it with a partial tautology: they are the things you should do because they are the best, or words to that effect. What people don't seem to understand is that there is no one voice declaring what is best, and even if there was, it would still be just an opinion. I've been frustrated many times when I was told to do something because it was Best Practice, even if it didn't fit the requirements. Who decides that it is best practice? How did they reach that conclusion? Why should we listen to them?

I've been told to further normalise a database which was already in 3NF, by adding a joining table for a 1:many relationship, because this is apparrently best practice. I've been told to break a class with only 2 methods into two smaller classes because this is best practice. I've been told to create an empty constructor in a language where an empty constructor replaces the (necessary) constructor from the parent class, thus breaking my exception tree, because apparently this is also best practice. In reality, these 3 different people all decided that they were wiser than me and used Best Practice as a meaningless argument.

In the first example, this person knew a few facts: many to many relationships use a joining table, thus everybody uses joining table, thus I should have used a joining table. They missed the fact that joining tables are used in a many:many relationship out of necessity, rather than because somebody somewhere wrote an article and decided it was best.

In the second example, this person had implemented a much more elaborate version of the same system, in which the two classes were larger, and separating them made sense. What they failed to notice was that my system was just delegating to a procedural texture loading API for use in a small game, while theirs was wrapping up a custom built texture loading API for an AAA game.

In the third example, this person saw somebody do this in a tutorial, but in a totally different context. Not feeling comfortable that I had empty classes (who's only purpose was to be leaf nodes in an exception tree) they felt that I wasn't doing Best Practice, i.e. what everybody else was doing.

I think that the best antidote to the feeling that you are a cowboy yourself would be to adopt defensive programming.[/quote]
Which itself is a best practice!

According to who exactly? I often recommend it, but I'm still really a beginner. This is a typical example of why I dislike the term - people use it to give their own opinion the appearence of having additional weight - you are basically pulling an argumentum ad populum by suggesting that a large number of people agree with you.
[/quote]

The solution, which I have now learned to provide in future, is to provide a data access method along the lines of getPageSafeData() which performs all the page safe escaping for you. This way, next time I work with noobs, I can be sure my data isnt going to inject nasty things into their pages.[/quote]

I don't think that will necessarily help you. The bad programmers will likely not use your new safe getPageSafeData method and will pull out the data themselves. After all, they could have easily used the built in [color="#1C2837"]htmlspecialchars method to escape the data, but they didn't. Unless they have ego problems or are really bad programmers, I think a better approach is education. Point out why what they are doing is bad, and how they can prevent that in the future. There is a good article somewhere over why trying to write code to protect against bad developers is a bad thing, but I'm having trouble finding it right now.
[/quote]

Needs must when the devil drives. Having had this bad experience, I've decided that the "best" way to avoid such problems in future is to provide a safe data access option. The alternatives is more people blaming me for their oversights, or disallowing control characters in user input.

Since what is best is a matter of opinion (everybody has different criteria) the only real way to determine what is best is to objectively look at the known facts.

Regarding the justification of best practices: I can see your point. I can ask someone why their peers do something in a certain way, and if their response is along the lines of "It's just been the way we've been doing this as far as I can remember", then I really haven't learned anything haven't I? Going up to the seniors who have been battle-hardened seem to be the better way to go for getting an answer worth keeping. Poorly educated people can't teach you well, obviously.

[color="#1C2837"]Sounds like you've never worked at a small company... That hasn't been my experience at all. I can understand how your suggestions could be ignored at a large company, but it's definitely possible to change the direction of software development at a small company, I have done it at practically every company I have worked at. It's worth pointing out that his existing company really needs him to step up to fill that role. It sounds like there is no project manager. No established SDLC procedures, etc. There is a hole there that an ambitious developer could fill.[/quote]
[color="#1C2837"]
[color="#1C2837"][color="#000000"]Actually, for the record, we do have project managers. In fact, they outnumber both our salespeople and in-house developers combined, and there's not a lot of steps that separate the CEO from the junior workers. Most of the managers just lack technical understanding and only discuss non-technical business matters, like project scope, targets and deadlines. We don't get to discussing normalization of tables or configuring modules for third party systems because it won't be of any benefit to discuss things that are beyond their area of understanding. In the first few months of working at this job, I was offered a promotion to project manager, and I decided that it will dull my already small set of technical experience.
[color="#1C2837"][color="#000000"]
[color="#1C2837"][color="#000000"]My current project is kind of unusual, though, in that the client is also the project manager, so he's pulling double duty. And I am pulling double duty as well, because I have to sit in and speak directly to the client in addition to working on his product. The company structure seems to discourage the growth of a tiered dev team (my boss went on to say that they don't have a need for an in house senior developer) because the actual heavy lifting is done by an offshore team (not outsourced, company owns a majority portion). I could research SDLC procedures and take a couple steps in programming above the rest, but I am not certain if that will really get me that far in this kind of setting. Being a pioneer of change doesn't come easy for most, and I would prefer looking for something that's already "there".

I think you are putting "senior" people on way to high of a pedestal and have it built up as they are some kind of font of the "best way" of doing things. I think you are going find far more of them are stuck in their ways because its always how they did it and are unwilling to do it "better" because their way already works. If you are wanting to jump on every new best practice that comes along then its going to be up to you to figure it yourself. And if something does work (and has for years) why dump it for a totally new way of doing things because somebody else has labeled it a "best practice"?

[color="#1C2837"][color="#000000"]Actually, for the record, we do have project managers. In fact, they outnumber both our salespeople and in-house developers combined, and there's not a lot of steps that separate the CEO from the junior workers. Most of the managers just lack technical understanding and only discuss non-technical business matters, like project scope, targets and deadlines. We don't get to discussing normalization of tables or configuring modules for third party systems because it won't be of any benefit to discuss things that are beyond their area of understanding. In the first few months of working at this job, I was offered a promotion to project manager, and I decided that it will dull my already small set of technical experience.

[color="#1C2837"][color="#000000"]My current project is kind of unusual, though, in that the client is also the project manager, so he's pulling double duty. And I am pulling double duty as well, because I have to sit in and speak directly to the client in addition to working on his product. The company structure seems to discourage the growth of a tiered dev team (my boss went on to say that they don't have a need for an in house senior developer) because the actual heavy lifting is done by an offshore team (not outsourced, company owns a majority portion). I could research SDLC procedures and take a couple steps in programming above the rest, but I am not certain if that will really get me that far in this kind of setting. Being a pioneer of change doesn't come easy for most, and I would prefer looking for something that's already "there".

Wow. Let me show you a different perspective. A lot of people would love to be in your shoes. Do you know what it takes to become a project manager in large corporations? PMP certifications. If you look up the requirement of becoming a certified PMP, you will learn that it involves thousands of dollar, taking tests and record of hours of project management. If I were you, I would've taken the Project Manager promotion. It was a path that I almost took about a year ago, but later I dropped it because I realized project management is just project management. PMP certification is a bunch of lies people trying to make money off other people's career. I am sure they will spend a month learning Microsoft Project, a month learning how to read Gantt chart, a month analyzing impacts of late deadlines given all sample scenarios, all of which could be learned easily from experience.

If what you are craving really is the experience of working in groups, and your company isn't offering you that opportunity, then the best you could do either:

1. Start your own group with your friends, preferably with somebody who's had the experience. That way, he can lead the team.
2. Look for another job that allows this opportunity

Though TBH, it's not anymore exciting than cowboy coding. Like everything else, it has pros and cons.
Pros: Somebody is there to cover you. So you can take sick days knowing that they got you covered.
Cons: it's not your code, other devs might not be as smart and probably really sloppy. It can drive you insane sometimes. Since you guys are team, you cover his ass too.

Just to clarify, it is the concept of Best Practice which I have issues with. Most people I have asked about this define it with a partial tautology: they are the things you should do because they are the best, or words to that effect. What people don't seem to understand is that there is no one voice declaring what is best, and even if there was, it would still be just an opinion. I've been frustrated many times when I was told to do something because it was Best Practice, even if it didn't fit the requirements. Who decides that it is best practice? How did they reach that conclusion? Why should we listen to them?

I've been told to further normalise a database which was already in 3NF, by adding a joining table for a 1:many relationship, because this is apparrently best practice. I've been told to break a class with only 2 methods into two smaller classes because this is best practice. I've been told to create an empty constructor in a language where an empty constructor replaces the (necessary) constructor from the parent class, thus breaking my exception tree, because apparently this is also best practice. In reality, these 3 different people all decided that they were wiser than me and used Best Practice as a meaningless argument.

In the first example, this person knew a few facts: many to many relationships use a joining table, thus everybody uses joining table, thus I should have used a joining table. They missed the fact that joining tables are used in a many:many relationship out of necessity, rather than because somebody somewhere wrote an article and decided it was best.

In the second example, this person had implemented a much more elaborate version of the same system, in which the two classes were larger, and separating them made sense. What they failed to notice was that my system was just delegating to a procedural texture loading API for use in a small game, while theirs was wrapping up a custom built texture loading API for an AAA game.

In the third example, this person saw somebody do this in a tutorial, but in a totally different context. Not feeling comfortable that I had empty classes (who's only purpose was to be leaf nodes in an exception tree) they felt that I wasn't doing Best Practice, i.e. what everybody else was doing.

Ok, I have a much better idea of where you're coming from and I agree, it can be difficult sometimes to distill what is actually a best practice, especially if you're simply putting trust in more "experienced" developers. However that doesn't necessarily mean that best practices are bad, just that you have to be careful of who you take advice from which is true of anything.

According to who exactly? I often recommend it, but I'm still really a beginner. This is a typical example of why I dislike the term - people use it to give their own opinion the appearence of having additional weight - you are basically pulling an argumentum ad populum by suggesting that a large number of people agree with you.[/quote]
I say it's a best practice because it's impossible to effectively argue against except in the most rare corner case. No one is going to say that you shouldn't be practicing defensive programming! Just like no one credible will say that you should be using global variables, or singleton's everywhere, or that premature optimization is a good thing. I don't think 3NF in a database is a valid best practice because there are too many instances where it causes problems. Call it argumentum ad populum if you'd like, but just because a lot of people agree about something, doesn't mean they are wrong

I think you are putting "senior" people on way to high of a pedestal and have it built up as they are some kind of font of the "best way" of doing things. I think you are going find far more of them are stuck in their ways because its always how they did it and are unwilling to do it "better" because their way already works. If you are wanting to jump on every new best practice that comes along then its going to be up to you to figure it yourself. And if something does work (and has for years) why dump it for a totally new way of doing things because somebody else has labeled it a "best practice"?

Along those lines, if someone recommends a best practice, but cannot explain why it's better than your current method, then your best bet would be to ignore it or seek better understanding of it before applying it. Clearly the "That's just how I've always done it" is not a valid best practice, it's a personal preference. However there are industry standard best practices that you'll be hard pressed to find (credible) disagreement with.

• Don't Repeat Yourself
• You Ain't Gonna Need It
• Keep It Simple Stupid
• Separation of Concerns
• etc...
  Those are the generic ones, but there are also best practices for each environment you're working in.

Wow. Let me show you a different perspective. A lot of people would love to be in your shoes. Do you know what it takes to become a project manager in large corporations? PMP certifications. If you look up the requirement of becoming a certified PMP, you will learn that it involves thousands of dollar, taking tests and record of hours of project management. If I were you, I would've taken the Project Manager promotion. It was a path that I almost took about a year ago, but later I dropped it because I realized project management is just project management. PMP certification is a bunch of lies people trying to make money off other people's career. I am sure they will spend a month learning Microsoft Project, a month learning how to read Gantt chart, a month analyzing impacts of late deadlines given all sample scenarios, all of which could be learned easily from experience.

If what you are craving really is the experience of working in groups, and your company isn't offering you that opportunity, then the best you could do either:

1. Start your own group with your friends, preferably with somebody who's had the experience. That way, he can lead the team.
2. Look for another job that allows this opportunity

Though TBH, it's not anymore exciting than cowboy coding. Like everything else, it has pros and cons.
Pros: Somebody is there to cover you. So you can take sick days knowing that they got you covered.
Cons: it's not your code, other devs might not be as smart and probably really sloppy. It can drive you insane sometimes. Since you guys are team, you cover his ass too.

You said that a lot of people would like to be offered the position of project manager, but when you took on the job for a while, you dropped it for the same reason I would. It's just project management. I prefer to stay to the code for a while longer, getting right down to the metal for solving problems. Only when I feel so confident enough to be consistently good at administering tasks and solve other people's problems would I consider a higher-level role like a lead developer or architect. I didn't know of PMP certifications until you mentioned them, and looks like I should be glad that I didn't.

Also, I feel we're getting to hung up on the legitimacy of "best practices" for programming as that isn't the only reason I would want to find a benefit for working in a team. What's very important to me is getting familiar with the communication aspect of team-based production. Things like, being able to document your version updates well, knowing how to respond to a scrum master versus a manager, how much input I should provide in team meetings, etc. These things are hard to come by when you're not sharing responsibility for the production.

Right now option 2 is the most probable for me and the one I'm working on, as most of my friends that are in IT (admittedly not many) have moved out of state.

...

According to who exactly? I often recommend it, but I'm still really a beginner. This is a typical example of why I dislike the term - people use it to give their own opinion the appearence of having additional weight - you are basically pulling an argumentum ad populum by suggesting that a large number of people agree with you.

I say it's a best practice because it's impossible to effectively argue against except in the most rare corner case. No one is going to say that you shouldn't be practicing defensive programming! Just like no one credible will say that you should be using global variables, or singleton's everywhere, or that premature optimization is a good thing. I don't think 3NF in a database is a valid best practice because there are too many instances where it causes problems. Call it argumentum ad populum if you'd like, but just because a lot of people agree about something, doesn't mean they are wrong
[/quote]

an ad populum is a void argument; i.e., its use does not mean the argument is false, it is simply not a valid argument. I do get that the use of an ad populum does not imply that the inverse of the argument is true. Anyway, I've been pleasantly surprised to find that people DO agree with me. Maybe software engineering Isn't so overrun by sheep as I originally thought.