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


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


20

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


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.


14

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


14

I actually keep a local wiki of code snippets and ideas. Its a really nice, productive way of organizing the small things that you don't immediately need. In general, there are a few rules you should follow if you don't want it to get out of hand: Give the snippets long, understandable names. This way, you know exactly what the snippet is about and how it ...


13

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


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


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

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

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


10

I'll go the other direction on this one: if your team has linux experience and familiarity, and you run your own servers, outsourcing to a .NET shop will be a disaster. You won't have the experience to rein in the outsourcers when they get crazy, your linux and PHP intuitions will fail you in the Windows environment, you won't easily spot goofy .NET ...


9

Counterexample to your examples: Apple's CEO is doing a pretty good job. There is no secret sauce. Some people can manage well, and others can't. A good manager can do a good job with a superficial knowledge of the subject matter. A bad manager can't do a good job, even if they're an expert. The absolute worst case is a manager who knows enough to be ...


9

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


9

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


8

For me: Disorganized when busy - lots of notes and sketches laid about Orderly when low on productive work - I clean up between projects or as transitioning between stages in projects How the project is going has to be judged by the number of caffeinated beverages at the desk + in the trash (the more beverages the worse the project)


8

If your language is OOP and package based (Eg Java), then you should probably keep each package in its own folder (eg my/package/name) to keep with the convention. If your language isn't package based (Eg PHP), then organize by what each file does. Here's an example Does this do utility functions? Goes in /util Is this a 3rd party plugin? Goes in /plugin ...


8

Ideally, yes. Anyone who writes code that other people use is not bound to provide anything complementing the code. However, if you want people to use your code (and everyone should always be writing with this mentality), extensive relevant documentation - which may include examples - are extremely useful. I don't think I've ever read documentation and ...


8

What you are looking for is the idea of Wireframing. I use WireframeSketcher with great success on all the graphical components of all the projects we work on. Whether it is a website, a desktop applicaton or a mobile application, the wireframing step is critical. Next step is Mock Ups where someone actually does the graphics and other things in ...


8

I doubt there is a One True Way. I think there's a lot of pluses and minuses to each. Here's my breakdown: Static Teams 1 time cost of team gelling ... or at least, team re-gelleing is 1:1 with corporate retention rates. more indepth knowledge of problem and solution can afford to have less consistency across groups and less documentation risk: Skills ...


8

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


8

I generally do my tinkering and new tech investigation on my home box. I just keep them all in their own directory under a general "Experiments" directory. They're usually not directly applicable, but they're often a good reference (e.g., when I was figuring out how to process Java annotations). I keep thinking I'll release some of the more self-contained ...


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

I would espouse team ownership over individual for the following reasons: Code consistency over the entire project Promotes discussion of code, which always leads to better, more vetted solutions If one team member is out sick (or worse), an entire section of code is not subject to delays Team members can work on all parts of the project, which serves to ...


7

I don't think there's any ideal mix- it's entirely project and environment dependent. A couple examples: All Experienced It might be appropriate to have all experienced team members on a critical project with a tight deadline, where there's no room for junior developers to get up to speed. All Junior In another example, it might be appropriate to have ...



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