Tag Info

Hot answers tagged

57

Forgetting things is normal. Not remembering some tricks that helped you in the past is also normal. This is the first step one should acknowledge. Then there are some ways you can "store" knowledge for further revision: Find time and blog about it. The future-you will be very thankful to the present-you; Work with tiny demos and archive them in some way. ...


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


42

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


39

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


28

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

Anything that causes context switching.


25

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


22

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

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


20

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


17

My key is Variety Repetition. Once can be fleeting. Seeing the 100th occurrence makes a difference! Memory by fingers. I remember code much better when I've actually typed it a few times. Code Library - Keep a personal stash of code and tricks you have used and seen. Centralization. I keep 1 file with all my usernames (hundreds) on 1 pc. I apply ...


16

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

Any attempt to follow a process that is not suited to the task at hand. This can be all sorts of things, but common ones I see include: testing methodologies that do not fit the code being tested processes that are dramatically more agile or traditional than the deliverable(s) warrant guidelines that are meant for a different toolset than the selected ...


15

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


15

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


14

Aren't name prefixes the same thing as namespacing, except that it's done in a way that is less useful and more difficult to read/parse? Doesn't the question answer itself?


14

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


13

Politics eg: When more than one person owns the requirements (or worse, two different vested interests), and they make competing and conflicting changes to the requirements whilst development is underway.


12

I really like what Eric Brechner has to say on this subject Think of your team as a river instead of a lake. A lake stagnates. There’s no energy or impetus to change. The same is true of groups that stagnate. They cultivate mediocrity and complacency; they abhor risk. A river is always running and changing with lots of great energy. You ...


12

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


12

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


11

I don't know in what context it was mentioned in the course, but the bin directory is usually (almost always) where the binaries/executable files are located. It is the directory which usually doesn't go under source control, and gets rewritten every time upon each new build. I hold no sentimental value towards it.


11

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


11

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


10

My take is that a cross-functional team is a team that includes people from the different functions of a company: engineering, IT, technical writing, marketing, finance, legal, sales, HR, operations, quality, and executive. In larger companies, these "functions" are put into silos (lines of management), but to get things done you generally need the time of ...


10

Almost impossible to answer this without being the project manager. Self-organizing teams could work, with proper communication. Or you could group 3 developers and 1 QA person together to make 7 "commando" teams. If you don't have enough senior devs to lead 7 teams, organize teams around the senior devs. Unless the senior devs don't want to lead teams. ...


10

Personally I would not work anywhere that I didn't have the opportunity for direct client contact. Trying to resolve an issue with the requirements when you have to go through layers of PMs and BAs is painful and the message never gets through clearly. I want this access to improve the product so that it actually reflects the clients needs and not the ...



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