[font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"]Long story short, I have been a web dev guy for about 5 years. So I guess I should be mid-level by now, but I sure don't feel mid-level. Save for one short job, I've been hired by places that require me to fly solo- ie. I'm either the only "tech geek" in the office or there's little opportunity to work with the only other in-house developer. This has lead to stagnating growth in my knowledge base and adopting best practices.[/font][/font][/font]
[font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"] [/font][/font][/font]
[font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"]I haven't touched upon a lot of stuff concerning formal software development processes, and quickly learned that coding is just a small part of the equation to the process of delivering a software product. As the only coder responsible for a product there really hasn't been enough time devoted to research and refining approaches to fixing problems, so a lot of stuff is done "cut and dry".[/font][/font][/font]
[font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"] [/font][/font][/font]
[font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"] [/font][font="arial, verdana, tahoma, sans-serif"]So how do you get out of this rut? How can I adapt to working in a team of more experienced developers? A lot of places that are built on SaaS and their developers as the backbone of their business interview me with questions that make it obvious to them that I haven't worked with a technical team. I feel like my cowboy coding habits have been working against my employment opportunities.[/font][/font][/font]
I've been "cowboy coding" on the job most of the time. How do I get away from it?
Look for another job. Find a company that doesn't interview you much about software development process.
TBH, I don't like companies that interview developers about software development process. It's completely irrelevant.
TBH, I don't like companies that interview developers about software development process. It's completely irrelevant.
[font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"]Long story short, I have been a web dev guy for about 5 years. So I guess I should be mid-level by now, but I sure don't feel mid-level. Save for one short job, I've been hired by places that require me to fly solo- ie. I'm either the only "tech geek" in the office or there's little opportunity to work with the only other in-house developer. This has lead to stagnating growth in my knowledge base and adopting best practices.[/font][/font][/font]
[font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"] [/font][/font][/font]
[font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"]I haven't touched upon a lot of stuff concerning formal software development processes, and quickly learned that coding is just a small part of the equation to the process of delivering a software product. As the only coder responsible for a product there really hasn't been enough time devoted to research and refining approaches to fixing problems, so a lot of stuff is done "cut and dry".[/font][/font][/font]
[font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"] [/font][/font][/font]
[font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"][font="arial, verdana, tahoma, sans-serif"] [/font][font="arial, verdana, tahoma, sans-serif"]So how do you get out of this rut? How can I adapt to working in a team of more experienced developers? A lot of places that are built on SaaS and their developers as the backbone of their business interview me with questions that make it obvious to them that I haven't worked with a technical team. I feel like my cowboy coding habits have been working against my employment opportunities.[/font][/font][/font]
I think you're going to be sorely dissapointed when you do work with a group of "more experienced" developers. The vast majority don't seem to care about any of the things you mention and it can be an incredibly frustrating experience for someone who's truly interested in getting better. You can't rely on others to make you a better developer, you have to make the time to do it yourself. You say there is not enough time to research and refine processes... How many hours are you working exactly? Most of my self improvement time as a developer are done outside of work hours.
Look for another job. Find a company that doesn't interview you much about software development process.
TBH, I don't like companies that interview developers about software development process. It's completely irrelevant.
Depends on what you want to do... To be a great developer and an instrument of change in a company, you need to know what works and what doesn't. Especially if you're working at a company with a poor or absent SDLC policy. If you want to be just another cog in the machine cranking out code then sure... try to get a job at a big company where all you have to do is crank out another widget and let others worry about how to best get projects done.
Don't underestimate the possibility of improving yourself on-the-clock as well. Spend 20 minutes reading about some best practices, spend 2 hours implementing it at the next realistic opportunity. You still get work done, and you still learn; as a bonus, if you play your cards right, you get work done faster over time because you are learning. This gives you even more time to shop for better skills and/or employment opportunities.
Don't underestimate the possibility of improving yourself on-the-clock as well. Spend 20 minutes reading about some best practices, spend 2 hours implementing it at the next realistic opportunity. You still get work done, and you still learn; as a bonus, if you play your cards right, you get work done faster over time because you are learning. This gives you even more time to shop for better skills and/or employment opportunities.
That could work as well if you're disciplined... I tend to go off on tangents. I can start looking into MVC, and four hours later be looking into the latest javascript frameworks. Needless to say, I spend a lot of time looking at new technology.
[quote name='alnite' timestamp='1318379625' post='4871672']
Look for another job. Find a company that doesn't interview you much about software development process.
TBH, I don't like companies that interview developers about software development process. It's completely irrelevant.
Depends on what you want to do... To be a great developer and an instrument of change in a company, you need to know what works and what doesn't. Especially if you're working at a company with a poor or absent SDLC policy. If you want to be just another cog in the machine cranking out code then sure... try to get a job at a big company where all you have to do is crank out another widget and let others worry about how to best get projects done.
[/quote]
As a self-improvement principle, then yes, you'd want to learn as much as you can to expand your knowledge and skill. However, most tech companies ask irrelevant questions to their interviewees just because they want the best candidate ever, regardless of what position they are looking to fill.
Successes of projects in a company depend on huge numbers of factors: CEO, management hierarchy, project managers, project executions, deadlines, visions, scopes, and many more. A single developer's vast knowledge about software development process won't have much impact on that. More likely he won't be put in charge to lead the project as his title is a "Software Developer" rather than a "Project Manager". Can he be outspoken and voice his concern and opinion what needs to be done during the course of a project? Sure, but whether he's going to be heard or fired depends entirely on the people running the company.
Successes of projects in a company depend on huge numbers of factors: CEO, management hierarchy, project managers, project executions, deadlines, visions, scopes, and many more. A single developer's vast knowledge about software development process won't have much impact on that. More likely he won't be put in charge to lead the project as his title is a "Software Developer" rather than a "Project Manager". Can he be outspoken and voice his concern and opinion what needs to be done during the course of a project? Sure, but whether he's going to be heard or fired depends entirely on the people running the company.
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.
The two most telling interview questions I ask every potential hire, before we even get to the technical interview are:
1) Why are you looking for a new position?
2) How do you stay current with the latest development practices / technology.
So many people answer #1 with "Because I want to learn about <insert new technology here>" which I find to be a ridiculous answer. If you want to learn a new technology, then learn it. If you're waiting for your employer to hold your hand while you learn something new you're already well behind the curve. Question #2 is really a follow up to the first to get a feel if this is someone who is really interested in programming or if they are just looking for 9 to 5 and a paycheck.
Long story short, I have been a web dev guy for about 5 years. So I guess I should be mid-level by now, but I sure don't feel mid-level. Save for one short job, I've been hired by places that require me to fly solo- ie. I'm either the only "tech geek" in the office or there's little opportunity to work with the only other in-house developer. This has lead to stagnating growth in my knowledge base and adopting best practices.
I haven't touched upon a lot of stuff concerning formal software development processes, and quickly learned that coding is just a small part of the equation to the process of delivering a software product. As the only coder responsible for a product there really hasn't been enough time devoted to research and refining approaches to fixing problems, so a lot of stuff is done "cut and dry".
So how do you get out of this rut? How can I adapt to working in a team of more experienced developers? A lot of places that are built on SaaS and their developers as the backbone of their business interview me with questions that make it obvious to them that I haven't worked with a technical team. I feel like my cowboy coding habits have been working against my employment opportunities.
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?
In my, perhaps limited, experience cowboy coders all seem to have the basic problem of not understanding, or if they do, not being concerned with, the implications of their work, and that is how I would define the term. I think that the best antidote to the feeling that you are a cowboy yourself would be to adopt defensive programming.
Some time ago, I worked on a website where there were several smaller personal organisation tools and a main browsing page. Users would create a to-do list at the end of each organisation activity. THis todo list was on most pages. I was correctly escaping all of the data, and tested all the usual SQL injection types to determine if my work was safe, and all was well. At least, it was with my work. But there was a problem - I had decided that the user should be able to add any kind of data in the description of each to-do item. On my pages this was fine, but on the pages of the other two programmers, who were putting data right out of the DB and onto the page without htmlspecialchars() escaping, there were several script injection faults. The reason for this was the combination of two oversights; I had not considered the implications of allowing users to enter any data, because *my* pages were OK with this data; I had gone off and asked somebody more experienced how to support this safely. The other two guys had not considered the implications of dumping data right out of the database, because their input data did not allow html special chars.
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.
Another good idea when you are coding something in which bad things might happen, is to have several hats (metaphorical hats). One is your programmer hat, which you wear while programming. The second is your script kiddie hat, which you wear while testing your code; you should try your hardest to make it break. In script kiddie mode, you should have the attitude that breaking the application in any way is a good thing. Finally, there is the Dumbass User hat: this hat should be worn in order to find problems of usability; Try your hardest to do the stupidest thing possible. How many mistakes do you have to make in a row before something goes horribly wrong? How would the dumbass user react to the failover conditions?
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.
Actually I have, and I actually got promoted from junior to lead there, and managed a handful of devs. Though the company was a total failure (CEO management nightmare), small companies do present more opportunities for growth and learning experience.
It's irrelevant, however, for a company to demand "understand agile" if all they are hiring for is somebody to write code.
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?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
