Fred -- Yes, I agree that programming is 90 % thinking. I'm surprised at how many people don't realize that. However, it is news to me if Agile does help anyone program. It seems a mass of status reports and paperwork (mostly on the computer, but same difference), and short meetings which rarely focus on any details or bring up different points of view.
I don't feel that I need a tool to tell me what the application needs to do. I think that common sense, and talking it over with whoever designed the app and the other people on the team (on a regular basis), can do that job. I know that applications should have as few bugs as possible and be easy to use and maintain. Sometimes figuring out how to make that happen is hard, and on a team it's important to pick a good strategy and have everyone stick by it.
I agree that good communication is important. I'm not going to straight up lie about not knowing something. I'm just not going to volunteer something that might make me appear less competent when I'm new at work. Just not smart to do that -- I don't think anyone can fault me for wanting to keep a job. My judgment of humanity is that we are unfairly judgmental towards other people ( ;) ), and I do not want to be judged.
Andrew -- I read the 16-page Scrum book Jeanne linked to. To me, how ideas are implemented are far more important that what they are in the abstract. Agile and other systems might sound great or awful in the abstract, but what really matters is how people actually use them. I don't put any stock in abstractions, buzzwords, corporate philosophies, etc., because most of the time they don't affect what actually happens day-to-day. Just a bunch of pretty words to dress something up. I have simple ideas about what makes a good workplace and a productive workplace -- open communication (which has to come from the top first as a sign of good faith), committed workers, and a willingness to talk about and accept criticism are three things that come to mind.
I'll glance over at the first chapter. And -- this is a promise -- if I do win a book copy I will read the whole thing.
1) Hm. It's a bit hard for me to separate out company practices and the Agile system since it wasn't explained to me. I feel like we rely too much on applications and virtual documents that are scattered in many places and all have their own logic about them. Learning them all has taken a good deal of time, and I think the tools are too specialized for the work I will be doing. It doesn't seem like there's much freedom yet in the ticket system -- that is, if say one bug is hiding three others, or if a bug and a bunch of other bugs are best dealt with by refactoring a large block of code, I'm uncertain that that would fit neatly in and be accepted. I also think that it's very hard to predict how long some problems will take, and that makes it difficult to be very definite about what will be done in a certain block of time. It's of course necessary to make predictions about what can get done, and without some kind of goal or deadline it'd be too easy for many people to slack off, so I can understand the necessity of structure.
2) …. I'm the new guy. No. Generally even if I don't like something, I won't say it until I'm completely sure about it, because rushing to judgment is very often a stupid thing to do. I'll still rush to judgment in my head, but I'll hold off on saying anything until I'm very sure, 'cause I know I could be wrong. And in the workplace I'm not going to say anything that's going to get anyone upset, unless there's really no choice and it's part of my job to do it.
3) I read the Scrum guide. I also do my best to understand all the tools and systems I'm supposed to use -- read the tutorials if I have time, or listen if someone is willing to explain it, or google it if I need to. Why I do things -- not exactly sure what you mean. I am at work to do what my boss says. That is what most jobs come down to. If you get really lucky then the job is mostly about doing a job, but that's only if your boss is a good boss and supports you in what you have to do instead of getting in the way. I get the feeling that programming is supposed to be professional job where there's lot of velvet on top of the you-are-at-work-to-do-what-your-boss-says, but really, that's what almost everything is.
I'm not trying to slink or be lazy or anything -- I really would like to do a good job.
4) No TDD -- I almost wish there was though because testing and documentation are an afterthought at best. I know there's supposed to be "continuous integration," which if I understand it right (working to produce software that is incrementally better and more functional) seems like common sense to me. Of course you should run your code all the time to make sure it works; it's nice to do tests on it all the time; and it's easier to fix bugs right when they come up -- so you should always strive for a working piece of software so that you know that your code does what you want it to do. Refactoring -- that might have a different meaning in the Agile world. To me it just means improving code that you already have and that already more-or-less works by doing things like adding documentation, making function/variable names more understandable, getting rid of repetitive code, making code more readable, creating new functions/classes to compartmentalize code better and make it easier to add functions/features or fix bugs, etc. I'm totally behind refactoring and when making a project bigger you have to do it on a continuous basis. Another benefit to refactoring is that you become more familiar with the code base, which makes it easier to use it effectively when adding features.
Jeanne -- Well, I really did owe you more courtesy. Even if I do doubt abstract corporate philosophies, I could have been a bit nicer to someone who thinks the opposite of how I do.