Hiring the wrong people
-
Well, I once worked on a team that had more business analysts then developers. They spent their time meeting with people making up projects to justify their existence even though they had no chance of getting built.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder
-
ed welch wrote:
The company that I work for hires the following: A project manager, a designer, and some programmers. Each one having a higher pay level and seniority. The programmers in this hierarchy are on the bottom rung and have no say in anything.
speaking of myths.... :) this is one of my nightmares. Even in a 2 year development project (let alone that I am now going on 13 years for this one project), the idea that you can always predict everything in design and then the programmers can just be grunts following orders without any ability to think for themselves.... you don't have to sign on to an agile concept to realize that even the best design will change during the process of actually writing the code. And forseeing the future is a very difficult job. Of course, if the manager and designer can successfully and accurately predict the future as well as design to it, sure they deserves a bigger check.... but otherwise, get some really good developers that can recognize and adapt to changing needs, its better in the long run. Just my 2 cents for what they are worth.... actually, what you later described is nearly our company. Though senior and junior developers will do design, I asked for and was granted the request that designs must be paired. Even if the two junior developers do a design, that means they agree on process, and with peer-design-review the senior developers get a word in (or often more, not that I am wordy, I just always say more than is needed... ;) ). :)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
That's a common misconception of the word 'Design'. It's not like every bit of information is written down on paper. Design refers to the way all parts of the application will interact with each other so when 2 pieces of code written from 2 different people come together, they work (with minimum adjustment if needed). If 'Design' covers GUI, Database, Network communication, Graphics, Data entry, Validation, Security, .... then the only thing programmers (Grunts) have to look out for is NOT to violate those rules, leaving them of plenty of freedom to write code / implement things the way they want.
-
someone to file all the TPS reports
-
I'd still want a non-techy paper-wrangler for all the crap that gets thrown around that developers are crap at handling. Developers aren't that great with money, paper trails, appointments, trademarks, proposals, reports, renewing domains and office leases, buying chairs, paper, pens, water and food. You need people to keep the coffee machine stocked. They do their job, you do your job. (I have long disliked the disrespect developers give everyone else in a company. They think they are the only people who matter when really they are part of the chain of business. Managers need to let developers do what they do best but developers need to leave managers to do what they do best.)
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
Paul Watson wrote:
Developers aren't that great with money, paper trails, appointments, trademarks, proposals, reports, renewing domains and office leases, buying chairs, paper, pens, water and food.
I disagree. These are things that require no specialist skill and anyone in the team can do them - remember this is a small project we're talking about. If there is enough of this type of work to keep one person busy 100% of the time, then that position is justified. But, why can't a developer buy a chair, that's just ridiculous?
-
Paul Watson wrote:
Developers aren't that great with money, paper trails, appointments, trademarks, proposals, reports, renewing domains and office leases, buying chairs, paper, pens, water and food.
I disagree. These are things that require no specialist skill and anyone in the team can do them - remember this is a small project we're talking about. If there is enough of this type of work to keep one person busy 100% of the time, then that position is justified. But, why can't a developer buy a chair, that's just ridiculous?
OK. A team of five developers in an office situation: - 5 desks - 5 sets of drawers - 5 chairs - Adequate space for 5 people - 5 computers - 5 network points - 5 monthly salaries - Office insurance for 5 people - 5 power points with plug boards - Water supply - Coffee supply - 5 contracts with yearly reviews - 2-4 waste bins - Waste collection service - Adequate electricity - Heating in winter, cooling in summer - Security for the office with 24/7 access - 5 income tax forms - Many, many more business tax forms - Adequate servers with offsite backup - Internet access - Cleaner service (carpets, chairs, desks, windows etc.) - Legal resource for disputes - Stationery supply - Domain setup and renewal - Business funds account with auditing - Bathroom facilities - Someone as the fire warden - Annual office safety and access checks - Someone to answer the phone - Someone to accept deliveries - Someone to send deliveries - Replacement contracts for equipment so that e.g. a failed screen doesn't delay work - Someone to make travel arrangements (flights, hotels, visas, rent a car etc.) You can "just buy a chair" but when it breaks and you have to sit on a cardboard box for three days because you don't want to use your own money to buy a new chair and you have no business process... well, its not just a chair. There is a reason good technology companies have a wall of non-techy people. They are there to deal with all the bits of life that we techies would rather not be bothered with. Some of it we could possibly do ourselves but to supply a team of even just 5 people on even a small project takes an efficient and knowledgeable administrator. I think your remarks are ignorant, ignorant of the good job many HR, PR and admin people do everyday. The HR girl sitting a floor above me keeps so much crap away from me it is unbelievable. She lets me get on with my job. Without her I'd be spending half of everyday dealing with admin instead of coding.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
-
OK. A team of five developers in an office situation: - 5 desks - 5 sets of drawers - 5 chairs - Adequate space for 5 people - 5 computers - 5 network points - 5 monthly salaries - Office insurance for 5 people - 5 power points with plug boards - Water supply - Coffee supply - 5 contracts with yearly reviews - 2-4 waste bins - Waste collection service - Adequate electricity - Heating in winter, cooling in summer - Security for the office with 24/7 access - 5 income tax forms - Many, many more business tax forms - Adequate servers with offsite backup - Internet access - Cleaner service (carpets, chairs, desks, windows etc.) - Legal resource for disputes - Stationery supply - Domain setup and renewal - Business funds account with auditing - Bathroom facilities - Someone as the fire warden - Annual office safety and access checks - Someone to answer the phone - Someone to accept deliveries - Someone to send deliveries - Replacement contracts for equipment so that e.g. a failed screen doesn't delay work - Someone to make travel arrangements (flights, hotels, visas, rent a car etc.) You can "just buy a chair" but when it breaks and you have to sit on a cardboard box for three days because you don't want to use your own money to buy a new chair and you have no business process... well, its not just a chair. There is a reason good technology companies have a wall of non-techy people. They are there to deal with all the bits of life that we techies would rather not be bothered with. Some of it we could possibly do ourselves but to supply a team of even just 5 people on even a small project takes an efficient and knowledgeable administrator. I think your remarks are ignorant, ignorant of the good job many HR, PR and admin people do everyday. The HR girl sitting a floor above me keeps so much crap away from me it is unbelievable. She lets me get on with my job. Without her I'd be spending half of everyday dealing with admin instead of coding.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
"I think your remarks are ignorant, ignorant of the good job many HR, PR and admin people do everyday." No, they're not. All I said was that they are general skills that anyone can do. and, I did say if there is enough of this type of work to keep one person busy 100% of the time, then that position is justified.
-
"I think your remarks are ignorant, ignorant of the good job many HR, PR and admin people do everyday." No, they're not. All I said was that they are general skills that anyone can do. and, I did say if there is enough of this type of work to keep one person busy 100% of the time, then that position is justified.
ed welch wrote:
No, they're not. All I said was that they are general skills that anyone can do.
Sure, with training and education and experience. Much like most of programming.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
-
ed welch wrote:
No, they're not. All I said was that they are general skills that anyone can do.
Sure, with training and education and experience. Much like most of programming.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
-
You don't need one to programme.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
-
And someone to wander around the office all day talking to people about the computer he has at home. :-D My Blog: allwrong.wordpress.com[^]
-
This is something I got to get off my chest. Supposing you want to put together a small development team, who would you hire? The company that I work for hires the following: A project manager, a designer, and some programmers. Each one having a higher pay level and seniority. The programmers in this hierarchy are on the bottom rung and have no say in anything. This is the most ridiculous crudgy inefficient hierarchy you could possibly devise. There is no justified reason for it. It's just done that way becuase "that's always the way they do it" How would I do it? Just examine what you need for the project, then hire based on the needs. Base the team on maybe one, or two senior developers. They would be good and be able to do all technical aspects, analysis, design, program and manage both themselves and the project and also specify the tools that they need for the job. Then, maybe a few inexperienced programmers. They would be supervised by the senior programmers and would learn from them. One of the senior guys would do the project management part time (maybe even rotating the task). Good experienced developers are able to management themselves mostly and having a dedicated project manager is redundant at best. At worst, they get in the way. This team would be half the size and twice as efficient as the one mentioned above. Don't forget the bottom line: money. The revenue from the successful project has to pay the salery of everyone
Your problem sounds more like a competency issue than a title/role issue. But first, as a development manager, I'll answer your question directly. It sounds like your project has about 5 people, maybe 3 of which are programmers. Going with just those numbers (without salary constraints) I think I'd personally hire one experienced software architect, 3 star programmers, and 1 entry level programmer. Basic project management of a project this small can and should be handled by an existing manager or executive, or even an existing project manager if one exists. There's no need to waste salary money (a lot of it by the sounds of your post) on a full time position. Also, I don't like the term designer because it implies a lack of programming skill. If by designer you meant software architect (someone who has spent maybe 10+ years programming and now, as a result, can engineer solid software design) then we are on the same page. Whoever is project managing should present the project requirements (and a client contact number) to the architect who should lay out the basic project design and rough schedule. The programmers can be brought in when s/he has a handle on the project and there are areas ready for development. With basic guidelines from the architect (guru), your star programmers (very talented) can handle most of the work, with the architect building only highly complex or high traffic systems, and guiding the design of the rest of the programmers. The one entry level programmer handles the mundane/repetative work that would be a waste of time for senior developers. (I don't believe in using entry level programmers for anything except a senior gopher. If you do otherwise, too many times the work is sub par and/or has to be rewritten.) Now back to your scenario. It shoulds like you can't change anything at current, the structure is already in place. As such, let me mention that I believe the team you have 'could' work, but you seem to be implying that the upper two hires (PM and designer) are not laying out a project that the programmers believe in, and they are not listening to advice from the programmers on how to improve it. My advice to you is to foster communication. Keep in mind that the designer and PM may be intimidated by the programmers at this point and as such may be standoffish. At the risk of being off base here due to lack of information about your situation, I think I'd try a very low emotion, highly professional board room meeting that lays out existing issues the programmers have identifie
-
Just follow the 7 steps of software development. 1. Analyze (What it is that you're gonna make. All aspects of it + Near future features). 2. Design (How things should be done to ensure speed / reliability & security). 3. Setup (Workflow control / Crisis handling / Communication channels / Hierarchy). 4. Equip (Buy the tools / Build the required testing structure / setup the entire dev proccess). 5. Develop (Build the damn thing). 6. Test (In house testing, Limited public beta testing, bug fixes, ... etc) 7. Release (Marketting, release, website, ... etc) ----------- ANALYZE This is done by the Marketting people, Sales reps. The Lead programmer (tech superv) only speaks to set the limits on features just so the non-ITs don't go asking for Star-Trek things like teleportation and such ... DESIGN Lead technical manager + All development staff (the heads anyway). This includes Network / Internet / Hardware / Databases / Programming ... etc. SETUP !!!! Lead technical manager + Project manager + Department heads (if any). Make sure you define the Who/What/How/When variables. What must be done during development, by Whom, How and When. It's also very crucial to have a procedure to handle crisis such as errors, failures, data loss, member resignations, ... etc. If a company already exists and works, this scheme is more or less defined already. However, it never hurts to refine things once and a while. EQUIP Lead technical manager + All development staff. Define the best technologies suitable in oder to LIMIT THE TIME !!!! Buy or build the infrastracture to test / data entry / deploy the application during development. This is MOST IMPORTANT as it's a major time eater. DEVELOP If design / setup / equip stages are all cleared up, this proccess is fairly straight forward. TEST & RELEASE Sorry, this is not my field. I'm only an IT person .... :) ---------------------- Bottom line is that you get the required people of the required skills, to cover all those stages. Some companies prefer to hire just before each phase but regardless, you'll most certainly need the guy that has the original ide/concept, a skilled Technical manager and of course the project manager (who ONLY OBSERVES & SUGGESTS by the way) to draw the limits on what & how it can be done !!!
You forgot 8. & 9. 8. Search for the innocent. "Find people low on the ladder to blame for any mistakes that happen. 9. Lorals for the non-participants. "Glory to the upper management that had no idea how it got done but take the fat bonus home for it getting done.
-
This is something I got to get off my chest. Supposing you want to put together a small development team, who would you hire? The company that I work for hires the following: A project manager, a designer, and some programmers. Each one having a higher pay level and seniority. The programmers in this hierarchy are on the bottom rung and have no say in anything. This is the most ridiculous crudgy inefficient hierarchy you could possibly devise. There is no justified reason for it. It's just done that way becuase "that's always the way they do it" How would I do it? Just examine what you need for the project, then hire based on the needs. Base the team on maybe one, or two senior developers. They would be good and be able to do all technical aspects, analysis, design, program and manage both themselves and the project and also specify the tools that they need for the job. Then, maybe a few inexperienced programmers. They would be supervised by the senior programmers and would learn from them. One of the senior guys would do the project management part time (maybe even rotating the task). Good experienced developers are able to management themselves mostly and having a dedicated project manager is redundant at best. At worst, they get in the way. This team would be half the size and twice as efficient as the one mentioned above. Don't forget the bottom line: money. The revenue from the successful project has to pay the salery of everyone
Anything that requires significant software development requires experienced professional developers. I think most CEOs, and business managers often look at programmers as production people, but that mind set is so wrong and I hate it! There is nothing worse than administrative people that don't get programming, or worse, the ones that think they get it but have absolutely no clue. Hiring inexperienced programmers to build your software is like hiring ants to construct a skyscraper. Developers are architects of information, not production workers repeating the same task over and over again. Good post Ed, I agree with you 100%
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
-
All my friends are complaining about their colleagues that they write crappy code so they go redo things all over again .... Not enough analysts i guess .... go figure :laugh::laugh:
Hrmm...Doesn't everyone write crappy code? Except for the code that gets posted on CodeProject... ;P
-
You forgot 8. & 9. 8. Search for the innocent. "Find people low on the ladder to blame for any mistakes that happen. 9. Lorals for the non-participants. "Glory to the upper management that had no idea how it got done but take the fat bonus home for it getting done.
Do i detect some tiny bit of frustration :~ .... hmm, maybe some hidden 'I wanna chop all executives into :mad:' type of killer anger ... :laugh: NEWSFLASH Tragedy hit a small town software company when a mad underappreciated programmer caused massive hysteria. Reports said that he barged into the conference room and abused a project manager with a mic, speaker set, mouse, keyboard, a laser printer and the photo copier. Proctologist experts have anounced their supprise as to whether such extend of abuse could ever be possible !! Fellow managers and colleagues of the victim stated their proffesional oppinion "We know that everything can be done, we simply don't know how !!" :->
-
This is something I got to get off my chest. Supposing you want to put together a small development team, who would you hire? The company that I work for hires the following: A project manager, a designer, and some programmers. Each one having a higher pay level and seniority. The programmers in this hierarchy are on the bottom rung and have no say in anything. This is the most ridiculous crudgy inefficient hierarchy you could possibly devise. There is no justified reason for it. It's just done that way becuase "that's always the way they do it" How would I do it? Just examine what you need for the project, then hire based on the needs. Base the team on maybe one, or two senior developers. They would be good and be able to do all technical aspects, analysis, design, program and manage both themselves and the project and also specify the tools that they need for the job. Then, maybe a few inexperienced programmers. They would be supervised by the senior programmers and would learn from them. One of the senior guys would do the project management part time (maybe even rotating the task). Good experienced developers are able to management themselves mostly and having a dedicated project manager is redundant at best. At worst, they get in the way. This team would be half the size and twice as efficient as the one mentioned above. Don't forget the bottom line: money. The revenue from the successful project has to pay the salery of everyone
Im sorry but I have to disagree on one point. The fact that you use these "super" senior developers in your solution. Theres no such thing as a senior developer who can design (actual design, not just the production of nice imagery) do all technical aspects, programming and self/team management while doing a good job at all of these. Its not possible. I dont care what anyone says, I am a designer in a small development team and your structure although nice to think of, would never fly. See the problem with bosses and CEO's is they are non technical. They may be technical enough to know where the company and solutions need to be, but unless they've got some ounce of programmer in them, they dont know what it is or takes to be (or hire) a good programmer. They will also promise things that are outlandish for the same reason. They just dont know. Aside from our CEO being a Senior Developer, what works for us is having the Designer (myself) work side by side with the developers because no one is amazing at everything. I take care of the UI and if the coders come across something that wont work with my design, we'll work on it together. Same if i come up with something innovative in my design, I will work closely with the programmers to ensure the right results and at the end of the day everyone is happy. If a programmer tried to tell me how to design or took it upon himself, I'd laugh and would probably look like crap. Same thing if I went around trying to code c# and design and manage people, the coders would frown upon it as my code would be sub-par, and just simply the project would be not of optimal quality. So, I think the best way to do it is have a project manager (full time) let him manage the project and timelines. You have your 1 or 2 senior developers and 2 or 3 juniors to learn from the senior like you said. Thenn let the designer cover his own end (providing he had actual design knowledge and isnt some kid with a copy of photoshop), or if hes not good enough for that, get an Art director/senior graphic designer to work with him.
-
Im sorry but I have to disagree on one point. The fact that you use these "super" senior developers in your solution. Theres no such thing as a senior developer who can design (actual design, not just the production of nice imagery) do all technical aspects, programming and self/team management while doing a good job at all of these. Its not possible. I dont care what anyone says, I am a designer in a small development team and your structure although nice to think of, would never fly. See the problem with bosses and CEO's is they are non technical. They may be technical enough to know where the company and solutions need to be, but unless they've got some ounce of programmer in them, they dont know what it is or takes to be (or hire) a good programmer. They will also promise things that are outlandish for the same reason. They just dont know. Aside from our CEO being a Senior Developer, what works for us is having the Designer (myself) work side by side with the developers because no one is amazing at everything. I take care of the UI and if the coders come across something that wont work with my design, we'll work on it together. Same if i come up with something innovative in my design, I will work closely with the programmers to ensure the right results and at the end of the day everyone is happy. If a programmer tried to tell me how to design or took it upon himself, I'd laugh and would probably look like crap. Same thing if I went around trying to code c# and design and manage people, the coders would frown upon it as my code would be sub-par, and just simply the project would be not of optimal quality. So, I think the best way to do it is have a project manager (full time) let him manage the project and timelines. You have your 1 or 2 senior developers and 2 or 3 juniors to learn from the senior like you said. Thenn let the designer cover his own end (providing he had actual design knowledge and isnt some kid with a copy of photoshop), or if hes not good enough for that, get an Art director/senior graphic designer to work with him.
Formative Innovations wrote:
Theres no such thing as a senior developer who can design (actual design, not just the production of nice imagery) do all technical aspects, programming and self/team management while doing a good job at all of these. Its not possible. I dont care what anyone says, I am a designer in a small development team and your structure although nice to think of, would never fly.
Well, sorry to disagree with you, I can do all that stuff and do it well. However, certain tasks are performed better by a group of people (for instance, the UI design), so really you need two or more of your developers pooling their ideas together for that, but you don't need a specialist UI designer. It's just natural that you learn to do more stuff as you get more experienced
-
Do i detect some tiny bit of frustration :~ .... hmm, maybe some hidden 'I wanna chop all executives into :mad:' type of killer anger ... :laugh: NEWSFLASH Tragedy hit a small town software company when a mad underappreciated programmer caused massive hysteria. Reports said that he barged into the conference room and abused a project manager with a mic, speaker set, mouse, keyboard, a laser printer and the photo copier. Proctologist experts have anounced their supprise as to whether such extend of abuse could ever be possible !! Fellow managers and colleagues of the victim stated their proffesional oppinion "We know that everything can be done, we simply don't know how !!" :->
No just a fact of being an employee...:laugh: When I was an employee this is how I felt, When I was a manager, my goal was to protect my team and do the best job we could for the company. Now that I'm an owner, I try to remember how I felt and make everyone feel appreciated and that their thoughts, dreams and fears are listened to and respected.
-
Your problem sounds more like a competency issue than a title/role issue. But first, as a development manager, I'll answer your question directly. It sounds like your project has about 5 people, maybe 3 of which are programmers. Going with just those numbers (without salary constraints) I think I'd personally hire one experienced software architect, 3 star programmers, and 1 entry level programmer. Basic project management of a project this small can and should be handled by an existing manager or executive, or even an existing project manager if one exists. There's no need to waste salary money (a lot of it by the sounds of your post) on a full time position. Also, I don't like the term designer because it implies a lack of programming skill. If by designer you meant software architect (someone who has spent maybe 10+ years programming and now, as a result, can engineer solid software design) then we are on the same page. Whoever is project managing should present the project requirements (and a client contact number) to the architect who should lay out the basic project design and rough schedule. The programmers can be brought in when s/he has a handle on the project and there are areas ready for development. With basic guidelines from the architect (guru), your star programmers (very talented) can handle most of the work, with the architect building only highly complex or high traffic systems, and guiding the design of the rest of the programmers. The one entry level programmer handles the mundane/repetative work that would be a waste of time for senior developers. (I don't believe in using entry level programmers for anything except a senior gopher. If you do otherwise, too many times the work is sub par and/or has to be rewritten.) Now back to your scenario. It shoulds like you can't change anything at current, the structure is already in place. As such, let me mention that I believe the team you have 'could' work, but you seem to be implying that the upper two hires (PM and designer) are not laying out a project that the programmers believe in, and they are not listening to advice from the programmers on how to improve it. My advice to you is to foster communication. Keep in mind that the designer and PM may be intimidated by the programmers at this point and as such may be standoffish. At the risk of being off base here due to lack of information about your situation, I think I'd try a very low emotion, highly professional board room meeting that lays out existing issues the programmers have identifie
-
This is something I got to get off my chest. Supposing you want to put together a small development team, who would you hire? The company that I work for hires the following: A project manager, a designer, and some programmers. Each one having a higher pay level and seniority. The programmers in this hierarchy are on the bottom rung and have no say in anything. This is the most ridiculous crudgy inefficient hierarchy you could possibly devise. There is no justified reason for it. It's just done that way becuase "that's always the way they do it" How would I do it? Just examine what you need for the project, then hire based on the needs. Base the team on maybe one, or two senior developers. They would be good and be able to do all technical aspects, analysis, design, program and manage both themselves and the project and also specify the tools that they need for the job. Then, maybe a few inexperienced programmers. They would be supervised by the senior programmers and would learn from them. One of the senior guys would do the project management part time (maybe even rotating the task). Good experienced developers are able to management themselves mostly and having a dedicated project manager is redundant at best. At worst, they get in the way. This team would be half the size and twice as efficient as the one mentioned above. Don't forget the bottom line: money. The revenue from the successful project has to pay the salery of everyone
I forget exactly where, but routinely at www.joelonsoftware.com he makes it clear that Developers Are the Star Performers there, as of course at Google. Coincidentally (?) the home-page-topic at this very moment is his new book "Smart and Gets Things Done" explains how to hire the RIGHT people ! Maybe you ought to drop a copy on the desk of your bosses - I have not read "Smart..." yet but I HAVE read "User Interface Design for Programmers" and it gets across some crucial principles in a very few pages, in contrast to those filibuster-style-tomes we dread.
pg--az