Slashdot Mirror
Ask Slashdot: What Defines Good Developer Culture?
An anonymous reader writes "I'm part of a team of six people developing applications for mobile devices (Android & iOS). In our company, which consists of many teams responsible for 'classic' software development, business intelligence, virtualization, hardware, etc., we are kind of a small startup because we were the first to use agile methods like Scrum and we are open to new technologies and methods. Also, our team is pretty young — I'm the oldest at 30 years of age. We would like to further raise productivity and motivation, so we're currently collecting ideas about what makes a good developer/hacker culture, and how it can be improved in our team/company. These can be things we do ourselves, or suggestions we pass on to management. I would like to know: what, in your opinion, defines good, modern developer culture? What does developer culture consists of? For example, is it: clearly defined career opportunities? A geeky office? Benefits like trips to extraordinary conferences? Please let me know what you think."
Soon we'll be using rasberry pis bought with bitcoins in the year of the linux desktop.
To offset political mods, replace Flamebait with Insightful.
An emphasis on keeping high-quality & intelligent developers. Don't ever let intellectually lazy developers onto your team.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
I've seen many different developer cultures. Keep in mind people are not clones. What works for one set of people may not work for another. In an attempt to be trendy and hip, some groups seriously backfired. Ultimately, get to know your team and adopt whatever works for keeping your team productive, happy and constantly improving. This will vary from team to team. There is no substitute for getting to know your team and practicing decent project management.
I now work in a very great job at a university, but prior to, I worked as a social media developer at __unnamed company__. While my background was in programming using C++ and derivatives, I also knew php and Javascript so it wasn't a stretch to start working there, building Facebook apps and such.
They got me on board for a somewhat decent (out of college) hourly rate and gave me 250,000 shares of stock to sweeten the deal. Working remotely, I'd do 2-3 weeks onsite at the home office, and 2-3 weeks off, during the off times going back home - I got more done when I was at home, truth be told. I'd have to be up all hours of the day, sometimes getting 3-4 hours of sleep in between being called to fix some mistake someone made.
I ended up having to wait 2-4 weeks for my paychecks sometimes, all the while the boss was wining and dining people, and flying all over the place. I let it slide, and eventually got a bonus system added to my pay for completed work.
The 4th time I was to be paid a bonus (for taking over the role as sysadmin on top of everything else, as the previous guy left), I got paid but then they put a new guy over me, who got salaried making 3-4 times what I was, who used a completely different language than any of the other developers in the company. Three weeks later my boss breached my contract. I'm contemplating litigation.
From my experience there, you should most definitely always pay your employees first, and treat them with respect. Furthermore, going geeky and loose on schedules and such is fine, but you should require 40 hours a week from everyone, regardless of when or where they get the work done. Incentives are nice, but don't make them too good. Further, treat everyone equally in terms of praise and respect...Finally, make sure not to allow drama in the office, it only destroys companies from the inside out.
As an added bonus, you should make sure and not allow drinking and drug use in the work place. My former employer did, and there were a lot of useless sponges that just sat around drunk/high all the time.
I've worked for three companies that did it, and we wasted more time with process than we spent getting actual work done. Instead, study the waterfall method and learn the good parts and bad parts from it. Then implement waterfall in a iterative process. Some people call that the spiral method. You'll have good disciplined iterations rather than intentional half-ass sprints like you have with agile.
Read everything you can by Joel Spoelsky.
http://www.joelonsoftware.com/
But meetings do serve a good purpose in a company like the plans on what to do next, whats going on right now, the reports, all those things a boss and other employees can communicate to each other when they don't have time. Meetings do serve that purpose and others like acting as a guide or a light in a big ocean as it's very easy to lose track. Taking 30-60 minutes per week minimum can help a company a lot since most of the time they work and don't have time to talk to each other. Just don't have too many since employee might get pissed off and demoralized by it.
and adapt the methods to suit your envinorment.
Don't stick to the letter of their methods, stick to the principles.
Don't be afraid to admit that you are wrong and change track.
Be honest and cut the bullshit.
Have fun and take the team out for some beer (or whatever).
Having a "geeky" office with tons of amenities will not do much for attrition if the team is beleaguered with the usual office politics or uncontrolled management pressure that affects many IT and development houses. Based on what I've seen with my few years of working experience, I strongly believe that the most important element in a successful developer-oriented culture is encouraging continuing education and the proliferation of ideas. From what I've seen, this requires having a management team that is *really* good at separating the wheat from the chaff when client or business demands come in and having a team that has very good chemistry with each other. This is really hard to assemble, since it's already somewhat hard to find people that fit what companies want from a technical perspective and harder still to find people that will gel well with everyone else, especially when the pressure cooker starts getting hot and work flows in.
Fair remuneration is pretty damn important too, but a bad office culture will only attract people who are looking to gain in the short term. There is a hedge fund that is notorious for this here in the East Coast; they pay their IT staff *wayyy* over market but have office politics that would put the US government to shame and an extremely socially stifling office culture that makes it tough to stay there longer than six months.
Good luck!
For me its flexibility in the hours I work, access to training, and being able to write the kind of code that I think should be written for a project.
By flexibility to don't mean full time or part time, I mean that I can come and go as a please as long as I meet my project requirements and make my time.
Training includes classes, conferences, research projects, and access to research materials such as books and hardware.
I've worked for a couple of companies where I was just a code monkey who was only allowed to fill in the blanks that my betters left undone. That kind of job is a nightmare of poor design and implementation.
10: PRINT "Everything old is new again."
20: GOTO 10
Don't be afraid to tell your boss about it. It might save your ass or make you work longer. It also helps a lot to know what your boss knows in terms of contracts, clients. Trying to know about your company really helps as you know if it performs or not. That way you know if you have to look elsewhere or not.
Some lessons that I have learnt from being a developer the last few years: I hope some of them help. Some of them are tech and some are about work culture in general. 1) Developers make mistakes. Don't have a culture of trying to blame things on someone. If you do see problems you can bring it up with the team in general and try to figure out the how to prevent such issues in the future. 2) Try to have lots and lots of documentation. In fact make that as part of your code check in strategy or bring that up during code reviews. 3) Remote working facilities are a must. Most people I have worked with are starting families and need flexibility in work times. Having flexible start and end times and ways to take meetings from home are super helpful. 4) Lastly respect your developers. A good word thrown in occasionally does not hurt. The people I see around me have all put in a lot of effort beyond the usual to get a product out successfully, however, the congratulatory emails always go to the managers with a word for the developers thrown in. A good product really needs a smart and experienced developer. If you keep a culture where your developers hang around because they like to work there, code maintenance becomes much easier.
If your team only consists of the smartest people in the world who have the ability to work with others, then your team will respect each other. This reduces the unhealthy type of politics and allows everyone to just work together to create the best product ever.
Allow these people to utilize their intelligence, have ownership in the product, and be able to find meaning in their work. Everything else is just perks.
* Place you can learn. It helps to have smart coworkers you can learn from. If you fit in, they'll learn from you, too.
* No dumb arguments. In some ways this is unavoidable among developers, but I hope to never have another argument about whether the variable should be named 'i' or 'index.'
* Realization that some ideas and designs can be different, but still be just as good as your own.
* Respect. If someone writes code that works, is readable, and is flexible, they deserve respect. Good coworkers have respect for each other.
* Flexibility. Let people finish their tasks on their own time, even if that means they like working from 2AM-10AM. If they like to do good work, don't harass them with unnecessary details.
There are productive meetings and there are not so productive meetings. A lot of effective management is shielding your people from the unproductive ones and getting the right people to the others when needed. At 6 people that's pretty easy to do.
No sir I dont like it.
You know, the kind of "methodologies" that managers use to feel important and sophisticated.
http://programming-motherfucker.com/
I think the single most important attribute for any technical person, and thus for the culture, is intellectual honesty. This includes things such as:
Admitting candidly when you do not know something
Actually listening to other people's ideas and opinions
Giving credit freely
And a friendly, rage-free culture doesn't hurt, either.
expandfairuse.org
The solution is obvious: have a meeting to discuss the usefulness of meetings.
As a consultant I've working in dozens of offices around the world and seen it all. The top factor is people. The best offices were those staffed with people who have the ability + desire + motivation to complete the work. Even just a few sub-par or bad attitude people in any role (managers, customers, testers, analysts) spoil it for everyone else. Have people write code during interviews, hire people on 1-6 month trial contracts before hiring permanently.
Next is managers who frequently inspect the work being done. If a manager isn't technically capable or doesn't regularly inspect work products in detail, then he/she isn't really managing, they are just hoping. Status meetings are not good enough if all that happens is the "manager" asking people to evaluate their own work/progress. Also daily meetings are a pain in the ass, what works better is accelerating in frequency of meetings as a release gets closer: at the start of a 6-month project once a 1-2x/week meetings are good enough, the week of a major release twice daily meetings may be required.
Methodology? General rule: more risks/unknowns need more iterations. Waterfall is most efficient for an experienced team developing their 20th LOB app in an enterprise of known customers. New team + new tech + new customers? 1-month sprints to incrementally deliver progress is a better choice despite the inefficiency.
Environment wise, triple monitors are the way to go. Most people acknowledge that two monitors are better than one, but three really is the sweet spot. Three gives you one central focus with two periphery that just works better.
Remember citizen, fun in mandatory!
Transparency: Don't hide business motivations or other important business information from your employees. They may have valuable input to share.
Flexibility: If you're primarily a software company, being flexible with your employees costs you little. Allowing them to work at home occasionally helps, and if you're flexible with them, they're likely to be more flexible with you when you need additional hours to get something out.
Openness: Hire good, intelligent generalists, and let them come up with the best solutions. Don't micromanage; hire people you won't need to micromanage. Further, let your team, especially the developers, use whatever solutions they think are best. Operating system, editor, hardware, whatever. Obviously for your actual product you'll need consensus, but anything specific to one developer should be up to them as much as reasonably possible.
Speed: Resist just about everything that increases the time it will take for you to come up with a working solution. As a startup, speed is your biggest asset compared to bigger software companies. Keep it as long as you can. (This doesn't mean that you should avoid planning at the beginning of a project, just that you should keep your business systems free of red tape as much as you can.)
I hear recruiters talk about companies with "awesome cultures" and how they have "Xboxes in the office" and all sorts of "perk" things like that. Those are great, but it's not the reason I'll want to work somewhere, because in the long run they mean very little.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
I think a more general statement would be to be flexible not dogmatic. To realize the agile is just the buzz word of the day. Like all the processes/methods that preceded it, it has both good and bad ideas. That the best practices touted by all of these processes/methods are sometimes pretty specific to the environment/tasks/workflow that the authors worked in. That the best practices suggested are probably not universally applicable.
Experiment, keeps what works, discard what doesn't.
But meetings do serve a good purpose in a company like the plans on what to do next,
A bug tracker + email is better.
whats going on right now,
Bug tracker + email
the reports,
Email
all those things a boss and other employees can communicate to each other when they don't have time.
Email + Instant messenger
Benefits:
1. Fast responses in general (don't have to wait for the meeting)
2. People can respond when they have time (doesn't disrupt work)
3. Doesn't take any time if you have nothing to say (no pointless meetings)
readily available supply of Nerf weapons
I've nothing to say here...
More old people. If the oldest in your team is just 30, then there's surely a huge amout of experience and expertise and wisdom that you're simply missing.
I think it's important to have structured feedback moments, and one of the most important and central tools I found to agile development (but it probably applies to all development) is using retrospectives (retros). In the company I work at, we do them after each code sprint, every two weeks.
In a good retro, you find about what is hurting your ability to work and define actions against those blocks. An easy to run retro which usually yields some useful results is the Mad/Sad/Glad retro:
Create a big area with three columns: what makes you mad, what makes you sad, what makes you glad. This can be on a big sheet of paper, a whiteboard, virtually (like Google Docs), ... Every team member creates as many small notes as they want and put them on the right column. This is more useful if everyone has to think for themselves and is not influenced by others (eg: create post-its on yourself, then hang them in the right column), and/or if it's done anonymously (eg via some software tool). When everyone posted his/her things, every team member casts votes on what they want to discuss. You discuss the most voted-on items, and try to formulate one action for each to improve on it. You typically want SMART actions: Specific, Measurable, Attainable, Relevant, Time-bound - aka well-defined with a clear goal.
Retros should be time-boxed, there should be a neutral "facilitator", everyone should be able to participate, no-one should have to hold back his opinion. A few people who try to discuss for the sake of discussion can be a good thing if it's not overdone: try to use every technique to get people talking and spouting the unhappiness, acknowledge it, and fix it.
In the last few months, we've splitted our team, installed new tools, decided to start reading groups, and brought more candy, all out of retros.
One CS student VS 893 DOS games: Let's play oldies
Research has shown that the only way to produce high-quality software faster than anyone else is to hire top-notched programmers. Top programmers always outperform average ones regardless of the methodology, language, or platform they use. If you want to be the best, hire the best.
Don't stop where the ink does.
The most important part of developer culture I look for is an emphasis on training. I'm flexible as to culture, development methodologies, etc., but without education, my resume could get stale enough to trap me in a job I no longer want.
The continuing education doesn't have to be expensive ('college courses'). One-day seminars, internet training, or even presentations on a topic by other developers in the company, can help keep the skillset up-to-date .
Culture is a polite term for clique. Maybe I'm just a bit cynical; but that's how I see it. You don't need to create culture. It happens organicly. You are doing the right thing when 40-something men with kids can code alongside 20-something lesbians and get the job done. What matters is that they can both write low defect code that the other person can maintain. Period.
If you focus on culture, you'll probably just end up creating yet another brogrammer shop. Best case scenario, you'll lose a good dev becasue he doesn't fit your "culture". Worst case, you'll get sued for discrimination.
You need to hire a middle aged ex IBM or Apple manager who doesn't code but is very good at playing politics.
Oh wait, that's the way to completely fuck up a small company.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Start with enthusiastic people. Then, don't kill their enthusiasm with corporate BS.
Keep an open mind - good ideas sometimes come from really whacked out places.
Don't make criticism personal.
Understand that shit happens. Schedules are almost never correct in the first place, nor written in stone: people will not die if you don't ship by whenever.
Keep things challenging and interesting. Who wants to work on a dead-end project in a dead-end company?
Foster an "egalitarian" mindset. Sure, you'll have "alpha dogs" in any office, but people should be free to offer ideas and question others on an equal basis. An idea should stand on its merit, not on the person who's suggesting it.
Avoid UML, unit testing, instant messaging, pair programming, and Git. Total wastes of time!
Fans of these fads will think this comment is a joke. But I'm serious. I've worked on a lot of projects, and every one of them was dragged down by one or more of the things I mentioned.
Actually, unit testing is acceptable, but only in extreme moderation. The risk of going too far with it is so overwhelming, though, that I think the best recommendation is to avoid it, until you get really clear about the risk (time invested) versus reward (bugs reduced). If developers take more than 5% of their time developing tests, you've failed. If tests need to be frequently re-written to accommodate changes to various APIs, you're wasting more time.
If the team is productive, then don't eagerly seek and adopt new policies, procedures, or technologies to try to gain some hypothetical 10% productivity improvement!
Also, your goal should be to manage things well enough to keep coworkers in the office for under 8 hours every single day. If you feel compelled to keep people in the office longer than 8 hours on any given day, you've failed. If someone has to come in on a weekend, then it is an epic fail. You should be really clear about these things. The mark of a failing project is overtime and weekend time.
Email + Instant messenger
Benefits:
2. People can respond when they have time (doesn't disrupt work)
Only if your boss doesn't ask 5 minutes later why are you not responding to email.
Extreme Programming - Redundant Array of Inexpensive Developers
There are productive meetings and there are not so productive meetings.
I recommend you read up on what this guy had to say about operations and engineering.
You may find many of his ideas surprisingly applicable to software development.
The solution is obvious: have a meeting to discuss the usefulness of meetings.
Yes but you can't rush right into a meeting like that. Often it takes four or five pre-meeting meetings before going into a meeting like that.
I'd like to emphasize that what works varies from person to person, not just from group to group. That despite what the currently in vogue development model tells you, best practices are not necessarily universal. Two highly skilled developers may have radically different best practices. That forcing a single set of practices upon a team may adversely affect the performance of a particular individual. The team leader needs to recognize such situations. For example one agile/scrum school of thought may advocate breaking work into very small tasks that are somewhat randomly assigned, a particular developer may bounce around different parts of the program from task to task. This works for some, not for others. Some skilled developers are far more efficient if they get the chance to specialize in a particular area for a while. Others may get bored doing so and prefer the bouncing around the project. Others may be indifferent. Don't fight against what works best for the individual. And make sure you communicate why some are working in one manner and others in a different manner, that its a matter of their individual styles not some sort of favoritism.
That describes pretty much every scrum retrospective I've been a part of.
I don't think it is intellectualism, its really whether the developer has an inherent interest in software development. Some people get a degree in CS because they have an inherent interest in developing software. Others get the degree because a parent or guidance councilor told them it was a good career path. A B student with the inherent interest will most likely be a far better contributor to your team than the A student who is on the career path.
The question is how to recognize the person with the inherent interest. Its a judgement call but I like to see what sort of stuff they wrote for their own personal amusement or curiosity. I don't really care how trivial or useful such code was. If a person has only written code for school or work projects that may be a warning sign.
No standing up! First that gets really close to agism. Some people say only 5 minutes max but it won't happen, some doofus will keep talking. Standing up as a goal to keep meetings short will not work, it will just make people feel uncomfortable and fidgety. The only reason to have one is if your company is too poor to buy chairs and the carpet is too dirty to sit on.
If you excuse yourself when you no longer feel useful, no meeting would ever last more than 30 seconds.
"Most meetings should involve two people. Sometimes three. Rarely more."
I disagree. Meeting need the person calling it to be a moderator, anyone would be able to call it when it starts to loose track, and develop a culture that respect those 2 rules. Some thing s are really to complex or require too many disciplines for meeting that small.
"Any meeting that involves more than three people should be done standing up."
Don't be an ass.
"Anyone should feel free to excuse themselves from a meeting when they feel their presence is no longer useful."
Absolutely.
"Meetings should have a written agenda and a clear purpose"
Absolutely.
"Meetings should have a clearly stated start time and a clearly stated end time. Never wait for late people."
depends. Sometime people will have meeting back to back. The culture I am currently in is 5 minutes.
"Meetings should have a designated note taker, and any decisions should be documented and disseminated."
Absolutely
"Most regularly scheduled "status" meetings are a waste of time"
I disagree. Have you ever worked on a multi-million project that involves a dozen or so different groups and disciplines?
Sometime that are needed. Does this mean every week and everybody? not usually.
And they should be quick. determine if the status are as expected. If there are problems that can't be solve sore explained in 30 seconds, set up a meeting with the people who know what you need.
Never, ever, bring sugar heavy food.
The Kruger Dunning explains most post on
Oh man! Hahaha! Whoosh on me! I laughed pretty hard when I finally realized that everyone was actually talking about sex.
UML is critical for many difficult system interactions. A single diagram can save several refactors later.
Unit testing is critical for good code. The point isn't to reduce defects the first time out of the gate. It's to reduce the likelyhood of problems being introduced the n'th time you have to refactor or expand an area of your application and need reasonable assurance that the impact of the change doesn't have a large footprint. You can change or add what is needed, run your tests to green, and be fairly certain that the application functions as intended in all tested areas. Otherwise, you're relying on instinct to tell you what the real effect on the applicaiton may be.
Instant messaging depends entirely on the culture and nature of your group. If your team isn't colocated it can be invaluable for every day work.
Git is no more a fad than CVS, Subversion, SourceGear, VSS, or any other source control. Source control is necessary. Your particular flavor of it may differ depending on your product, IDE, and approach. I like Git, but use Subversion more. Neither is a wrong answer, depending on the situation.
Good developer tools make all the difference. They get the hell out of the way of doing work.
(1) The biggest thing you can do to make people happy is fast builds. That generally means rolling your own, since tools like emerge/ebuilds and so on all have horrendous overhead. A null build of a product containing 500 modules (for example, an embedded Linux device) should take no more than 10 seconds. If it takes more than 10 seconds to do nothing, then you are doing it wrong.
(2) The next biggest thing you can do is proper build. Building is half the battle; the big thing that stops work is integration failure. Say you have 500 packages in a product, and you make a change to one of the packages; what should get rebuilt? The answer should be (A) the package itself, and (B) whatever depends on APIs exported by the package. Yes, this means properly expressing dependencies. This is hard. Boo hoo: you are getting paid because you do hard things that you ordinarily wouldn't do, except if you were getting paid. Get the hell over it. Doing things this way is incredibly important in order to resolve #1: If I can use binary build products for all the packages I'm not working on, obtained from a previous build, then all I have to concentrate on building is the things I'm currently working on. A 30 minute build goes down to a few seconds.
(3) This is necessary to resolving the build: Have strong inter-module contracts. A package that exports an ABI used by one or more other packages should damn well export a linkable library and header files. If the library version doesn't change, and the header files haven't changed, you don't need to rebuild the damn thing. But this can only be properly known if you have partitioned your packages such that they export ABIs. The ABIs should be documented, and these documents are contracts, where you agree not to break the contract from either end of things. A dependent package needs a new API? That's a negotiation. A Package wants to deprecate an API it exports? That's a negotiation, too.
(4) After build works, you need integration. Integration boils down to using branch tags in your source code control system. This is necessary when someone attempts to submit a change that breaks things: instead of being dead in the water until the change is fixed or reverted within the package, and waiting hours, the B&I team reverts the package version to the previous version, and you are good to go: Things take minutes, not hours, days, or weeks to resolve. The B&I team is God, but their deliverable is binary packages. This is important in support of #1.
(5) React appropriately when things go wrong. For example, if someone commits a test that's broken, but the test isn't exercised, and three weeks later the code path gets activated by a change and breaks things, do the right thing. The right thing is to back the hell out the change that activated the code path. The wrong thing is to try to fix the test at that point, while everything stays broken on the theory "Ah, this is a smiple fix, I'll just fix the test instead". You may look like a hero for fixing the test after a couple days or a week, but you aren't, you're the bottleneck who killed the productivity of the rest of the team while you were trying to fix the test. Bottom line: back out the proximal cause of the problem, and fix the root/distal problem out of band. Everyone gets to get more work done.
(6) Test appropriately. This is almost never done; most testing is reactive. What I mean by this is that people tend to write tests to verify that things are fixed, and then integrate those tests into their waterfall; that's a reactive test. This is almost never useful, since it doesn't verify correct behaviour, it only protects against regressions on a bug that was noteworthy enough that it's unlikely to repeat. Instead, testing should test desired product functionality. One aspect of agile programming that is a good idea is writing the functional tests before writing the code.
Read this:
http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf
And This:
http://www.nczonline.net/blog/2012/06/12/the-care-and-feeding-of-software-engineers-or-why-engineers-are-grumpy/
Watch This:
http://www.livestream.com/etsy/video?clipId=pla_780bfe22-12e8-4c7f-8c7b-06cc6cac9c49
That should get you started.
*) Don't turn your workplace into a fraternity.
*) a super-automatic espresso machine, and pay for all the coffee & maintenance of said machine.
*) Agree that you don't want to do anything stupid or wasteful even if some book, or person, think's its the 'best practice' or 'cool'
*) newer is not always better. Newer is not always worse.
Have a good boss. Really. He doesn't have to be the nice guy everybody loves. That probably won't help. His real job is to keep the management's political games away from the developers, and to translate between nerds and managers. Most times, your ideal boss will seem just to do some paper work, and not mess with nerds' stuff. From time to time, he will ask how far the project has progressed, and occasionally, he will tell you that the stuff really has do be done before a certain deadline, at least so far that the stuff does not crash within the first five minutes. And when things are really burning, he's the one that listens to you when you need someone to yell at.
That was my first boss, and I still miss his talents. My current boss is a moron. No clue of management and politics in management, no clue of project management, hardly a clue of software development, but he knows his computer well enough to find mouse, keyboard and power button. Unfortunately, this makes him think he could manage and administrate computers. And, my absolute favorite, his completely irrational optimism. If he would drive at 200 mph against a solid wall, his last words would be "I'm perfectly optimistic that I will survive the crash without a single scratch".
The most important thing: Keep end-user support away from developers. Nothing kills concentration more than a phone that rings every few minutes, with a completely clueless user on the other end of the line, telling you that his "computer does not work, and it's all your fault".
And, you may have already guessed that: My current boss forces me to support end-users, during development.
Tux2000
Denken hilft.
Try shortening and reducing your emails. The best thing to do is split all information into 3 categories. A) What a person doesn't know they need to know B) What a person knows they need to know C) What a person doesn't need to know.
Only stuff from category A should be send via e-mail. Everything in B and C you throw on a wiki, bug tracker, reference docs, etc so they can look it up themselves when they need it (instead of when you decide to send it). The only exception is a quick 1 line e-mail saying "the informatin regarding FOO you have been waiting for is now available at BAR" with a link to the resource.
Not only does this keep the e-mail volume low (and increase the chances that your employees get the information they need), it will also help centralise and enforce your documentation instead of fracturing it among 10 employee inboxes.
I never got a degree, mostly due to ending up studying the wrong area (electronics) and eventually falling out and not getting a degree. I'm quite curious to the actual worth of the degree, if all you're interested in inherent interests. I have a job as a software developer, so it isn't a personal question, just curious. I imagine there are also people who end up getting a non-CS degree, but have an inherent interest in software development.
A CS/CIS/etc degree is not required. It is quite plausible to study all the topics covered in a degree program on your own. The problem is that very few people who embark on that self-taught path will study all the necessary topics. It is too tempting to cherry pick the interesting topics and pass on the less interesting. The problem is that some of the less interesting topics can be quite important. "Less interesting" varies from person to person.
A formal degree program has the advantage that a person will be coerced into study all the relevant topics, "interesting" or not. Most people can benefit from that sort of formality. Add to all of this that one can get access to some pretty cool hardware at a university that one would not get access to otherwise. Plus there is the environment of being surrounded by others of similar interest and abilities. What you and your fellow students learn from each other complements what you get out of class. Some professors, but not all, can also teach valuable lessons not normally covered in class.
I have worked with some great programmer who never got a degree. I would be happy to work with many of them again. However they probably could have been even better with the formal training. Self study, practical experience and formal training are all good things. Each complementing the other and taking a person a little bit farther.
As for inherent interest, that is something entirely different from training or experience. IMHO a person who lacks an inherent interest in software development is unlikely to become one of the better developers.
If your boss can't leave you alone and let you work, then you have more serious problems than too many meetings.
I spent almost two decades in an older development environment, and can share some of our prized secrets for success. It helped to have a team lead who was REALLY good with threats and verbal abuse. Everyone needs "Ivan the Terrible" role models to help foster a nurturing environment of back-biting and finger-pointing. Another secret is to always replace a programmer who was not a good fit, with another even more dysfunctional misfit. Lead from behind. Set your best people up to fail. When forced into a product upgrade, poll the clients to ascertain what they don't want, and give it to them. Have your system architects study Machiavelli. Never fix code when a kludge or spaghetti code land mine can be concealed for the benefit of future generations. Programmers, make sure QA or beta testers follow scripts YOU control, or else they'll be wandering off on fishing expeditions to find inoperative features and broken functionality. Make sure all your people understand that broken GUI's and grossly inaccurate algorithms are "working as designed." Above all: the healthy development environment will insure that everybody, from VP to administrative support, lives in fear of their job and absolutely dreads going to work every morning.