59

There are several things you can and should do to prepare for the task: Think about the problem and draw some diagrams. Make sure that you know what the problem is that you are trying to solve. Do research on what you are trying to do. The internet is a valuable source of information. I am not saying ask Stack Overflow -- I am saying do research on how ...


47

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 ...


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 ...


27

There is no perfect solution, but some things that might help: Break tasks down into the smallest possible units -- break them down until you have things you can do. Restate the immediate task or problem at hand to make sure you really understand it. Then do some analysis and repeat. Pick the simplest task first, even if it seems too simple just to get ...


25

At my company, we use a separate SVN repository for every component of the system. I can tell you that it gets extremely frustrating. Our build process has so many layers of abstraction. We do this with Java, so we have a heavy build process with javac compilation, JibX binding compilation, XML validation, etc. For your site, it may not be a big deal if ...


25

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 ...


23

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

The terms describe very similar concepts and responsibilities, and in general they are somewhat synonymous. The term "DevOps" is a relatively new one, popularized by the Devopsdays Ghent 2009 conference and subsequent Devopsdays events. It's best described in this diagram: On the other hand, Software Configuration Management is a far more established term ...


18

Of course you have no idea how to write a "generic error mechanism". No one knows how to write a "generic error mechanism" until some requirements are defined. It sounds like all you have is someone's notion that a "generic error mechanism" is somehow required to start this project. Personally, I would push back on this notion. Writing "generic" anything ...


17

Someone needs to be the manager, but in your team's case, I don't think this is a full-time position. Hire another sr. dev and make one of them the manager. Ideally, the one who best fits being a manager and not necessarily the best programmer. The manager needs to have the final decision where there is no concensus, so the person should be technically ...


17

Most answers I see are rationalizations for the status quo, but really, I don't think there is a good reason for this state of things. Most programmers seem to believe not having a life is part of the deal and spoil it for the rest of us. Managers are good at screwing everybody around, unions are a joke, everybody says the economy sucks, but then there's ...


17

What I have done in the past is either convert the physical development machine to a VM, or if it is already a VM, retain it for future use. It's not as efficient as I'd like for disk space usage, but space is cheap. Also, this process is so much less expensive time-wise than trying to re-configure an environment in the future should the need arise.


15

I used to work at a company that hired good, motivated developers and kept them. But we still felt there was value in code review: it helps spread the knowledge and just because one person feels that what they've written is good code doesn't mean there isn't room for improvement. And we faced a similar problem. Coders preferred to code. To say nothing of ...


14

I've never heard of such a thing at any company that I've worked or interviewed for. Companies normally only want to pay for new features or changes that have measurable improvements for end users (like performance improvements). Refactoring code doesn't do this in a directly measurable way. What I've witnessed at companies that do understand and care ...


14

Short answer ... Start out with the repositories in your personal account. From there, if/when things grow and/or get popular with the community, move them to an organization account. GitHub Blog: Repository redirects are here! Long answer ... Let's look at some of your options: 1. Organization: For more information on GitHub Organization features, be ...


12

The weird "member of technical staff" title actually has ranks in it as well (depending on company). It used to have only two ranks (mts, dmts - distinguished) and both implied you have a Ph.D (or masters with equivalent experience). There actually is a technical title committee (at least in AT&T Labs) that one has to go through to get approved to hold ...


12

The simple answer to your question is yes as other folks have indicated. A more complete but more complex answer to your question is to address: "Management acknowledge this, but budget restraints limit our ability to recruit additional members to the team" Management saying "yes we acknowledge that, we recognize that" is just "words" to make you feel ...


12

When it comes to architecture it always depends. When building a simple throw away application you document way less than when building a large service oriented architecture. When building an application in an agile organisation you document less then when building an application in a highly governed waterfall organisation. When it comes to determining what ...


12

After quite some reading and tests, I have made a basic demo C++ project demonstrating the use of CMake, CTest + boost.test, CPack and Doxygen and using more or less the organization I mentioned in my question. The project shows how to make subproject dependencies, how to compile the whole repo or only a subproject, how to package, how to test and how to ...


11

I think you're suffering more from anxiety than a skill deficit. At some point, wasn't everything new? Have you ever been given a task and not been able to solve it to some extent? You're paid to figure things out. Utilize Your Team - If you're on a good team, you should be able to ask for help. There are things you'll know that even the most senior won't ...


11

My current favorite methodology is to maintain a script that installs ALL needed dependencies for a project, downloads the source, and hooks everything up. Some scripts have two modes - one for production, which usually is pretty much a subset of the other mode: development. Some environments only take about 5 minutes to install with a script - in that case ...


10

Yes and no :) Both developers and QA people should have the same goal (and their performance measured against that): deliver a quality product in time and on budget. You get to define "quality product", but it has to be the same for both groups. Why? Because if it isn't the same, you will get two groups with different agendas and that can quickly ...


10

Spoike's answer is excellent, but there are a few things I think it would be worth adding which are too large for comments. Branch organisation With Mercurial you can happily ignore the whole of your first organisational chart. As Spoke says, each repository has it's own set of tags, branches (named and anonymous) and can be organised according to business ...


10

Naming things by their properties is a fundamentally bad idea. The reason is that properties are, by definition, changeable phenomena, while the identity of a thing stays the same even if properties are changed. Someone decides that the file server should be migrated to Linux? If its name is "Apollo", that's not a problem. If the name referenced "windows", ...


10

There are 3 reasons, in my experience: When you have to name lots of similar things it can be hard to find unique descriptive names for all of them. People need a short unique way of referring to it, and we're better at using names than we are at using numbers (unless the number is very short). When you give it a name, it tends to take on a personality in ...


9

Okay, trying to answer this simply. What you need to know First thing you need to know: Mercurial is distributed version control and has some properties you should know about listed below. The source come from one repository, where that repository can be cloned. All cloned repositories can share code with each other through synching (with pull and push ...


9

Am I using namespaces wrong? Wrongly. It's an adverb. And the answer is probably. In use cases, which would you prefer? There are several reasonable tests. Is one easier to read, easier to say, easier to type, easier to fit in a readable expression or otherwise easier to use? Can you take something out without impairing clarity, legibility, usability ...


8

I don't agree with Developers make bad testers Most of the teams I've worked on in my career have not had any QA support. This includes a couple of large, global corporations involving products like their global login and registration system. In another case, I had 30% of the company's revenue running through a box on my desk. (These practices are not ...


8

Any project files which are needed for the production system (the application code + tests to ensure requirements compliance, configuration, cron jobs, and anything else which is part of your process) and which cannot be generated automatically (even using wget) should be in version control. Everything else can be ignored.


7

If a programmer knows someone else will be refactoring their code - he/she will NEVER bother to refactor their own work. Setting up a separate team to refactor is like justifying poor quality code existing in the first place. It's like acknowledging that there will be problems and then modifying your company's organizational structure to cater to it. I ...


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