Hot answers tagged

86

Why, as an employer, would you give up a competent, even great, developer, simply because he wants to work 3 days a week and not 5? More than one reason (all argued from the point of view of an employer): As Fred Brooks argues in the book The Mythical Man-Month, the efficiency of a team goes down as the team size grows, because the amount of ...


66

This is a classic issue in companies that have a software development component in their work, whether they are software companies or not. I struggle with this all the time. Having Developers involved in Production Support Pros Fights "Development in a vacuum" syndrome. It's valuable to gain exposure to how users use the app. Until I finally saw this as ...


65

"So all things being equal" They're not. These titles are not equivalent. I would rank them like this, highest to lowest: Principal Engineer Senior Staff Engineer Staff Engineer Senior Engineer / Senior Research Engineer In general, "senior" implies depth of experience and maturity to work independently with less direct guidance in day to day activities....


53

They are not supposed to be employer specific. Actually they come from the United States Bureau of Labor Statistics, which maintains a database of occupational descriptions. This database has a list of standardized job titles with fairly precise definitions for each one. In many professions, including computer programming, they have several bands based on ...


49

Oh this ones easy: Meetings More Meetings Meetings about the last meeting Meetings to prepare for the upcoming meeting Developing a power point presentation for a meeting Developing a power point presentation for a meeting discussing features that haven't been implemented, shouldn't be implemented, and for whatever reason that guy from sales will jump all ...


46

I believe that Team Ownership is much more beneficial in the long term. You just need to look at the following 2 scenarios to understand why concentrating knowledge in minimum numbers of people is less than ideal: Team member meets unfortunate accident Team member meets better employment opportunity Naturally, the person/people who write particular ...


45

The greater the risks, the more you need "air cover". This is what a manager is really supposed to provide. While the team does the work, the manager is supposed to ensure that there is nothing that will keep the team from achieving team goals. Whether it's tweaking the schedule, running interference between the team and the sales staff, or simply making ...


40

Wikipedia gives a good overview of corporate titles and under the hierarchy for Information Technology companies you have the following: Chief Executive Officer Vice President Senior Project Manager / Senior Product Manager / Senior Software Architect Project Manager / Product Manager / Software Architect Project Lead / Senior Team Lead / ...


35

One reason is that, as a manager, you get an ok to recruit one "head". Not fractions. One. This means, if you recruit someone part-time, you'll have to all effects one person in your team that does 3/5 of the work he/she's supposed to do or you will have to hire another person who wants to work the remaining 2/5. However you see it, this turns quickly into ...


31

The Short Version: There is no industry standard for these things, they're specific to each company and in some cases won't even be consistent within a single company. The skills and abilities that make someone a developer in one company might mean that they're a senior developer in another company, and a technical architect somewhere else. The Longer ...


29

There is no standard hierarchy of software job titles. Titles are peculiar to each company. If you have a question about a job title there's no point in asking anybody except that company.


29

Great question. There's some good answers hereabouts too, but overwhelmingly they appear to be taking the employers' perspective, so let me redress that a little. Firstly, I think it is great that you are wanting to take a better work/life balance than an ordinary 9-6 job will offer you. We who live in advanced capitalist economies often need reminding ...


29

Code review is a solution to a problem. Do you have a problem and will "Code Review" solve it? Are the other people checking in bad code? My guess is they are to some degree, but maybe your other coders don't think it is so bad that it is worth the time/effort to do a review. Ask your senior devs to come up with a solution to limit the amount of bad code ...


28

The only way to know for sure is to get a job description (list of responsibilities, expected skills) for each position. The qualifiers on these titles seem arbitrary and will vary from company to company.


27

Anything that causes context switching.


27

Ultimately, the team owns the code. But for all of the reasons you mentioned, we have designated individual authors for specific portions of the code. Each author has primary responsibility for their portion of the code, and secondary responsibility for the code base as a whole. If a problem with a part of the code base surfaces, I try to go back to the ...


25

StackOverflow, programmers.stackexchange.com, etc. :)


24

Warning: Anecdotal evidence follows.... In my experience, at least here in the Australian market - the terms Programmer, Software Developer and Software Engineer are more or less interchangeable (I've held all three for doing the exact same actual work). The "Software Engineering Director" described in your CNN link is not the same as "Software Engineer". ...


23

They are employer specific defintions. But generally they are a way to grade developers (for the purpose of salary and seniority). Each company is different but it will generally look like this: SD Requires no Experience. SD I Requires X years in the industry or Degree SD II Requires Y years in the industry SD III ...


23

We don't reference people by their characteristics as it takes all day to list them in enough detail to be unambiguous and the characteristics can change. What if they get a haircut? Instead we give them names. Also, people are better at remembering words than streams of random symbols. Disclaimer: This is going to contain some opinion and anecdotal ...


21

Is it actually possible to develop software without also architecting it? Yes, and either: Your software will suck or Someone else must be performing the role of architect. In order for software development to be effective there must be an architect, and if their team is large enough to warrant developers that are not also "architecting" (or ...


21

it is easy to hire developers This is the problem. The developers you hire simply are not motivated or don't have experience to keep the codebase in high quality. You should focus on hiring developers who take it upon themselves to keep the code quality high. And finding developers like that is extremely hard. Both because there are not many of them and ...


19

Project manager's point of view You are the single (or default) point of contact for anything related to the technical side of things. You are expected to keep the work of the other developers' moving by sheer force, leading by example, or whatever your method is. Not-lead developer's point of view You are the role model. Expect the lesser-experienced ...


18

Software Architects who become too disconnected from the actual coding process become ineffective. They must be developers themselves. As Uncle Bob Martin once put it: Even though [the software architect] is designing the whole thing, I think it would be appropriate for him to be able to dive down into [coding] for a day or two and make sure ...


18

While I agree from a business stance on reasons to spread the knowledge about the product; reality is that an individual focusing their efforts on a given area of anything will, over time, become much more versed in the given area. To ignore this is to ignore science. The brain unfortunately is unable to retain everything it encounters. It recalls what is ...


18

I think that developers already wear two hats. Support is more like a filter used to shield development from trivial issues such not having the computer plugged in. However, there should be tight coupling between development and support. Some customers have legitimate issues that maybe the result of a bug. It should be the responsibility of development to ...


17

Similar to Martin York's answer but I think the real way these things come about is the need for Finance (and subsequently HR) to define people as a cost.* When a new SE is needed, the manager will make a request to Finance through HR for a new headcount at particular job level. A better justification will be needed for an SE III than an SE I. HR/...



Only top voted, non community-wiki answers of a minimum length are eligible