As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
What's your opinion of the following job interview question?
In the requirement it never mentions about to have classic ASP experience.
But the question is "What are the differences between ADO.NET DataSet and ADO Record Set?".
I'm not an asp programmer, but since you've asked for opinions, here's one from Joel
Just for fun, here is the worst interview question on Earth: "What's the difference between varchar and varchar2 in Oracle 8i?" This is a terrible question. There is no possible, imaginable correlation between people that know that particular piece of useless trivia and people that Fog Creek wants to hire. Who cares what the difference is? You can find out online in about 15 seconds!
This is my favourite answer to these questions:
I'm sorry I don't know that; but
give me 5mins and Google I'll find
out for you.
I'd say it's a fine interview question.
Active Server Pages (ASP) != ActiveX Data Objects (ADO)
Some people ask what they know - and if you know it too maybe they like you :)
Well, they can even ask you whatever they want. About Perl, Python and Ruby, it is an Interview, they might be measuring your knowledge in other languages (if you heard about them, or if you know why .NET is better/worst).
The important thing in an interview is that you answer the questions to the best of your abilities, so what's my opinion, if you don't know then just say you don't know about ADO Record Set, but you list the benefits/features of a .NET DataSet
The best thing I've found in an interview if you don't know the answer to something is not sit quietly and then try and blag it. Be up front, say you don't know, but if you'd hazzard a guess then it would be insert educated guess here. The interviewer will appriciate the honesty, not everyone knows everything. People want to see confidence but also humility :-)
I'd say it's fairly pointless these days. Anyone who doesn't know probably just hasn't worked with old applications. All the ADO functionality has been out of date for about a decade now and there are some fine devs with years of experience that will just never have seen ADO.
I've hired a lot, and the difference between the really excellent candidates and the average ones is not what obscure things they know now, but what they can go pick up quickly when they need to.
In short a really good developer might answer this with: "I've never worked with ADO, but I could go find out", which isn't that useful for you as interviewer.
A more useful question would be
In what circumstances is it better to use a DataSet rather than iterate the rows of a table?
That way you get the important stuff - actual usage and technology application. They could answer in the context of Linq or a SqlDataReader or any other tech that they've worked with. What you get is what they understand and know how to use, not what they could Google in a few seconds anyway.
Probably they have some legacy code using the pre .NET version of ADO, and are testing to see if you have some knowledge of it.
I think knowing about the differences between ADO and ADO.Net is probably very useful in some positions.
If you've never done any classic ADO then you should probably just say so at the interview and move on to the next question.
Awful question if their goal is to test your capability as an engineer.
Reasonable question if your resume claimed you are both an ASP and ASP.NET guru, and they just want to see if you're telling the truth.
Of course if you work for a big corporate firm, they are more likely to just build their own DAL from scratch and use stored procedures instead of..........well, this.
I've asked a similar question at an interview although it was probably a bit more high level. I asked the candidate what he liked better about Java and what he liked better about C++. This was not some sort of "standard question" The candidate in question, in his resume and the interview up to then stated experience with both. I asked the question for two reasons. To check that the candidate actually has the knowledge he states (which could be a valid reason for the question on the ADO data/record sets). The second reason is to have the candidate show a degree of reflection and ownership of his tools.
In short, the appropriateness of the question is dependent on the profile of the candidate. If the candidate stated knowledge of both, let the candidate show his understanding. If this knowledge is critical to the job, same.
Related
I'm wondering building a website like StackOverFlow (approximately the same features using ASP.NET ) How much Work-power and time does it take in your opinion .
My boss has asked me to estimate for work-power , time , cost and suitable technologies .
I appreciate any direction .
I believe that the site would take plenty of time to implement. If I'd have to pull a guess of thin air I'd say somewhere between 800-1200 man hours.
Then comes the setting up servers, ensuring scalability, testing, fine-tuning algorithms.
So depending on how good you or your team is it could take anywhere up to a year to write something like this.
Disclaimer: I am just talking based on 10 years of experience with web-development. But I could be COMPLETELY wrong.
Buddy, there is a website similar to this called http://startups.com
You can probably ask this question there. Its specifically designed to answer questions like this. Whereas stackoverflow is intended for programmers and programming related questions. I see this question being asked here a bit isolated.
People come to this site and think wow stackoverflow this is an easy site to create.
I mean all it is is post a question then people submit an answer. I think that is a big misconception. Maybe just maybe the database is quite simple, a question has multiple answers and an answer has multiple comments associate with it. If you dig deep into it the questions and answers could actually be stored in the same table...with some indicator as to whether it is a question or an answer. But to answer your question, I don't think it is as simple as one might think. It's definitely not difficult in the logical sense (it's doable). What I am saying is it is more then a one week job :).
it is not that hard to do the site. the design is nice but simple. the engine isint THAT complicated (or so it looks). biggest problem is the load that falls on this site and the hard task of moderating/maintaining it. and the best part of it is the idea ;)
I think that the diffuclt of stackoverflow is to get community (very good quality community, not like yahoo answers).
Not only that, also use cases from stack overflow are pretty cool and adapt very well to get a good community.
About work-power a good skilled programmer could start it, if at full time like a month or less could do it. BUT! the programmer should have the idea,not a freelance or something like that, freelance or slave monkey coder could take a more time to do it.
But there are more problems, like money to invest at very begin of the app for example in hosting / server power costs.
Also stack overflow, could be compared to forums...its like a forum evoled or something similar.
Someone said that requires a lot of work power, I disagree if you start something to get the best scability,etcs (like project of big scale) you are going to death of that project.
Start something simple, very simple when there are scability problems start with that but no at begin!
Probably longer than you expect:
Code: It's Trivial (by Jeff Atwood)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
G'day,
I'm always trying to improve my performance as a developer and, after listening to this interesting podcast on the topic, I was wondering if people think it is worthwhile asking for feedback from colleagues.
I am thinking of obtaining feedback anonymously in the manner suggested in the podcast by using the Rypple site. And by asking one single, short question that directly addresses a specific aspect of my work or behaviour. For example, I'm looking at questions such as:
What can I do to improve the way in which the development team and the operational work together?,
How can I help you be more effective in your job interfacing with our major client?,
What parts of my technique could I improve based on the presentation I gave today?
etc.
Edit: I am not talking about general aspects, but specifically about how my performance as a developer can be improved. Communication and working with others is a large part of working with others in a company.
Edit: These additional questions are in response to a comment to my original question by JB King.
Further examples of possible questions that could provide useful feedback to help you improve as a developer are:
Am I becoming too focused or obsessive in my solution toolset?
What technology do you think I should learn to expand the team's capabilities?
What technology do you think I should focus on to improve the team's overall capabilities?
All of these directly address my personal progress as a developer.
cheers,
If you want to get honest feedback about what you are doing, you may want to find someone that observes what you do, and just ask their opinion, perhaps while having a beer. :)
But, it is important that you don't get defensive in any way, as you are asking for honesty.
And, you should consider making changes based on what they say, as that will help others to see that you are not only open to criticism, but willing to adapt, to become a better developer.
But, ultimately, you need to get an idea what type of programmer you want to be. Then it is useful if you have someone that you work with that exemplifies those qualities, then you can develop a relationship to see if they can help you become a better programmer.
For example, I knew an architect who would always pull a chair over and sit down when answering a question, so he was always on the level of the developer. That little action was so impressive to me, as it was a simple action, but it showed a willingness to bring himself to the level of others. That is how I want to be seen as I mentor others.
I think asking for anonymous feedback is bad, in part because it shows that there is a communication problem on the team, where people are not willing to be open with their feelings and opinions. The team lead should deal with that, as it could eventually be damaging to the team, if people keep their true opinions bottled up rather than expressing them, in order to help the team to be better.
I'd actually recommend not being anonymous when asking for criticism. One of your stated goals is to improve communication with colleagues; I think you might improve this better by actually talking with them instead of using a tool.
Being able to take criticism in person will show people you are confident and serious about improving. Face time is unfortunately underrated in our industry.
Yes, asking for feedback from colleagues is worthwhile. Often you don't know what you are doing great and where you could improve without getting at least a second opinion, if not a third, fourth, and so on.
Anonymity gives the benefit that those answering don't have to fear retaliation. Sometimes this works well and the result is honest feedback and sometimes people may enter stupid things trying to be funny. Que sera, sera.
I am not sure much good will come of it. I kinda agree with James on this one.
What might be better is to have some development workshops in your team. You could do it in such a way that each week 1 developer has the floor for an hour. Find a meeting room and a projector (if you have one) and let this developer present his / her discovery to the rest of the team.
At any point in time there are huge changes happening in the industry, so there should be a lot of areas to cover, for example - one week a certain developer could talk on up and coming changes in .net framework v4 (just an example), while another week yet another developer can talk about the benefits of shorter scrum iterations (again just an example).
The idea is the developer shouldn't be forced into presenting, and he/she should decide his or her own topic of interest.
This exercise might help strengthen communication in your team, and in this way the whole team is geared towards improving development skills.
This is the good idea, bad idea which I've seen is to take this idea too far, and expect developers to go away for weekends to so called coding dojos - yeah how fun (not).
Make sure these presentations are happening during normal paid business hours, or you'll have a riot.
"How can we do our jobs more effectively?" is a great question, and well worth asking!
But you should always discuss it openly. It's about as innocent a question as one can ask in the professional world, so if you tell people to discuss it anonymously, they'll think something funny is going on, even if that's not the case. And if you can't discuss such an innocent topic openly, your organization has serious problems.
Also, if you're going to ask questions like that, you need to pay attention to the answers, and either act on them or explain why you won't. People can handle, "Good point, but we're not going to do it that way, here's why." But it's pretty demoralizing to answer a question like that - especially if you made a lot of effort - and then feel like you've been ignored.
A good question that I've found to ask is: "Would you recommend this app to someone else?" and start the conversation there.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
There are many CASE tools, many software for diagrams, drawing, documenting. But can they replace old good paper?
Every day, all day! (Okay, not all day, but a lot)
I actually had a debate a while back on the value of psuedocode, and I was giving my input on how much pen/paper and some pseudocode could work wonders at times :)
I use computers to solve easy design problems, but when I hit something really hard I break out the powerful tools - pen, paper and brain.
I use a whiteboard for design and pen-and-paper for TODOs.
Especially when it comes to doing some math before the implementation, there's nothing better than putting it down on paper first!
No software can ever replace the sheer ease of jotting down ideas and solution sketches using pen/paper! EVER!
Once you have your critical thinking down on a paper you can take your time to beautify them using fancy softwares and tools.
All the time I use pen and paper, I find them invaluable tools to programming! Making notes, etc, etc...
Using quick sketches is an invaluable tool in clarifying requirements with a client. You don't have to be Da Vinci to quickly encapsulate complex business logic or UI behaviors in some simple sketches. Leah Buley at Adaptive Path has great resources on sketching for UX. Programmers can learn these techniques as well. You'll save a lot of time using paper first, before sitting down in front of Visio.
I vastly prefer pencil & paper (or pen & markerboard) for real-time thinking. It can handle just about anything my brain thinks of. If I need to create any official artifacts, I'll take what I've drawn and set it up using a tool. But usually the initial copy is sufficient.
On a side note, I'm still not sure why just about everyone in college switched to laptops for taking notes. You don't have anywhere near the ability to express your thoughts in Word as you do on paper.
All the time, especially for complex logic with lots of conditional programming!
I always find it easier to jot down what I'm about to draw/model before using application tools.
All the time. When I want to draw/write something complex, I don't want to master a piece of software to do it. Also means there are no extra applications hogging up my system resources. Plus, there's something satisfying about writing at all angles on a piece of paper :).
Most of the times when I program you can see papers all over my desk, some are wrinkled on the floor and some are not.
I usually do my brainstorming on paper and preliminary UML diagrams.
If only I had a whiteboard... :)
I don't use pen and paper when working alone, but I always use them when working with other people, talking with customers and so on. I mainly use pencils to draw diagrams.
In my opinion, the most beauty about programming, its heart its about designing good algorithm or pseudocode.
I thought before that a paper and a pen could be a good idea but I went ahead to write it, They were easy programs though, short ones.
I just approached the PNP question, not that I expect to resolve it but curiosity rules me,
You do not need to face such a big problem to use paper and pen but since I got into that I realized how important It is.
It saves time, makes you more efficient.
General while you are programming you concentrate in small concepts like: Is this variable int...?
To have a big picture of the program, the best way It is a pen, that lets you concentrate on a problem and the go with the technical stuff, memory management, security, fast code...
If you go directyle into the keyboard, You might spend lots of time creating a big powerful function to realize at the end You do not need that because It happens that variable "a" will always be negative or whatever.
But please trust me I just started programming but happily I have discovered the world of the pen and paper.
I just realized that your question is actually nor a yes no question is it about comparison with diagrams, documenting.
Pen and paper before writing the program.
Documenting while You program and that It is a good idea to use a computer, I mean of course You can document it with papers but having you code full of /* */ It is just faster and better to read it and edit it again.
So there is a place for both things but stick with the pen at the beginning.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
After investigating a little bit scrum and kanban, I finally read this answer and decided to start using kanban, picking something from scrum (note that I'm working mostly by myself, and I do have read this question and its answers).
Now, my question is: which tool would be best to get started?
whiteboard and postit
agilezen.com
JIRA with greenhopper
a spreadsheet (possibly on Google Docs)
brightgreenprojects.com
Agilo
Target Process
something else (please specify)
Notes about each:
I would lean towards the whiteboard, but there are several drawbacks (e.g. cannot make automatic charts, time measurements, metrics, and sometimes I work from home - where I need it most - and it's not convenient to carry :-)
I don't want to remember another username/password (I promised to myself to signup only to OpenID-enabled services)
My employer has JIRA but my group doesn't use it - I might ask for an account (it shouldn't require another password) and maybe later involve the rest of the group. But I don't know if they are using greenhopper and if it's a big deal installing it.
I generally hate spreadsheets
maybe overkill?
I'd be happy to have a localhost instance, but it could be problematic to give access to the whole group (per network/firewalls) - not a deal-breaker but surely a concern
What I'd like to get from this?
being more productive
tracking how much time I spend in any given task, possibly discussing the issue with my supervisor
tracking what "blocks" me most often
immediately see where I am compared to my schedule
manage in a better way my long todo list (e.g. answering faster to the "what I should do next?" question)
Do you have any suggestion?
Note on the scrumish tag: read the Henrik Kniberg's PDF. He first introduced the definition of scrumish on page 9.
If I may, I think that you are on the wrong path. Anything else than 1. or 4. is overkill and pretty much useless for a non distributed team. So for a team of one person...
Seriously, if you can avoid using a web based application, just do it. First, unless you are already mastering Scrum/Kaban, you need to learn the process, not a tool. Don't let a tool dictate the process. Then most web based tools are just too much click intensive, less easy and fast to update, less transparent/visible than a spreadsheet and a physical board. They are really 2nd category options.
So, I'd go for a spreadsheet and a physical board combo. If you need some charts (I'm still wondering what kind of chart/metrics you want to generate and what value they provide), a spreadsheet is the ideal tool (but honestly, you don't need any tool to draw a burndown). If you need to work from home, take the spreadsheet (or use google docs) and post its with you. Let's be objective, the impediments you mentioned are actually not real.
Last thing, if you had chosen the simplest thing that can possibly work, you would already be doing Scrum, Scrumban or whatever. So, instead of looking for a tool, my advice would be to just start doing it.
agilezen.com seems like the ideal solution for you. I have used it in the past solo for myself and it is convenient. I would not let a prejudice against non-OpenID sites get in the way of making a good choice.
pick the tool you already have, and start using it; don't let the absence of the "perfect tool" become an excuse not to start
EDIT: pick the simplest thing that can possibly work. In your case that would be whiteboard and postit notes. These have almost no setup overhead and will provide a constant visual reminder of what you're supposed to be doing.
And I suggest that you get used to making decisions on your own, as you're going to have to be your own Scrum Master ;-)
In the interests of diversity ;-) www.kanbantool.com has just launched too. It's open beta and seems at first glance even more "lightweight" than agilezen.
Target process is good too
We've been using JIRA with Greenhopper for a few months, in an effort to go agile. I use it for both Scrum for development, as well as for my personal kanban. The software is pretty flexible, and I'm going to keep with it. The story/subtask management is really handy, and it's fairly easy to use. One thing I like is that you can add stories/cards quickly, and can customize the data. This allowed me to add definition of done fields, work order numbers, etc.
In short, we're happy with it.
Bright Green have just launched a free version of their tool. It looks good .. the free version is fully functional too: https://signup.brightgreenprojects.com/plan/Free
I've tried out another kanban product for personal use and am absolutely loving this one. Feels lightweight and simple but actually packs in a fair amount of functionality at the same time.
www.kanbanery.com (free for personal use)
A novel tool not mentioned before is getsmartQ (out of beta since Dec 2010)
Key characteristics: very intuitive, supports LWP, customizable forms, and task discussions
Pros
configurable workflow, mark overdue stories, mail notifications (e.g., for upcoming story deadlines), multiple story owners
Stories form completely customizable, per project workflow and story forms, different roles (people only creating stories)
very responsive GUI with partial updates
Apparently good support: I've asked a question and got a good answer within a few hours
Cons
no easy way to declare something as blocked or to distinguish type (feature/bug/..)
no API
no subtasks or story dependencies
In comparison to Agilezen it has a more sophisticated notification system, but apart from that still lacks important features (see cons above).
Note, getsmartQ is under active development and hence missing features mentioned above may have been implemented in the meantime.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
In my work experience, most fresh out of school programmers are set right to creating reports for 6-12 months or so. While I see the benefit of doing something non-crucial, it seems to really discourage them.
So my question is, should organizations allow newbies to work with someone experienced right off the bat, obviously doing non-critical phases of a project, do get a real feel for what their career choice has in stock, or throw them on reports out of the gate?
Ah, there really is nothing like exploiting interns for remedial jobs...
Seriously though, you get back what you put in. Forcing them to do a thoughtless, thankless job for a long period of time is a quick way to build up a useless team member.
Perhaps they should be looking for a job at different companies? Maybe they shouldn't settle?
I was once a fresh-grad, and I have never been asked to work on a report. I had a programming check-in within the first 5 days of my job.
Maybe I am confused about the question. We are talking about folks who apply for programming positions and are sent to doing "reports" related job?!
I didn't start in "reports". I started on a conversion -- just get stuff to run on the new platform. Relatively safe, minor programming changes.
Then I did some new development for a while.
Then another conversion.
Then -- 2 years into my career -- no longer a complete n00b -- I wound up in "Reports". They wanted something like a dozen dumb-as-dirt accounting reports. Each was a "pull from the general ledger", "do some quick math" and "write a columnar report". [It was 1980, that's how stuff was done.]
I couldn't stand to do copy-and-paste programming. So I wrote a thing that extracted from the ledger into an array of values. It used a flexible notation for doing calculations on values in that array, then it wrote out the results of the calculations.
It could add, subtract, multiply and divide. You could use multiple operations on a series of "cells" to compute wonderfully complex things. To a limit.
I had invented the spreadsheet, built as a COBOL batch program. Seriously. That's what putting someone on reports can lead to. A single program that produced the dozen dumb-as-dirt financial reports. And a large number of additional reports, too.
Bonus. It was built in an Agile, incremental fashion. The first version did a half-dozen of the really easy reports. The next one did two or three more.
I don't think "reports" is a bad gig. What's bad is forcing people to copy and paste yet another dumb-as-dirt report program from a cookie-cutter template.
I believe it to be beneficial. It's what happened to me long ago and it provided me an opportunity to learn the database schema, the domain, and how the data is being used.
But, if they were hired as a Software Engineer they shouldn't be a report writer indefinitely. Programmer/Analyst however...
It's beneficial to the company in the short run, because then you can get useful work out of new graduates. It's harmful to everyone in the long run, because creating reports isn't really that hard, so the newbies don't learn much from doing it.
That being said, 6-12 months is a really long time to stick anybody on doing reports (unless they enjoy it, which most people don't). Maybe a shorter time period would be better training for a new employee.
I've worked in shops that threw a lot at the new hires where the results were mixed and I've worked at shops where they did pointless monkey-business exercises such as writing reports that nobody would read, attending 'process' meetings and open-ended tasks like "read a book about C++" or "learn something about this technology or that one. Both of these approaches were a waste of effort and time.
At my shop, if you are the new guy you aren't going to get left to your own devices to figure out X or to create busy work for yourself. Typically, we'll run you through our products so you are familiar with them as a user, then we'll talk through whatever task it is we need you to do, do the "I'm right over here, tell me if you need assistance" thing and then check up on them during the morning "what are you working on?" meeting. The goal at my shop is to get a developer up to speed as quickly as possible without skipping over the important stuff.
I think the key to successfully developing the new employee, particularly one who may be right out of school is to challenge them, provide them with interesting tasking that will make them not dread coming to work. If you get them interested in the work, you get an employee who becomes valuable. There are some tasks that just aren't interesting, and we all do them at my place. For me, I dread getting anywhere near MS Word to write formal documentation, but that comes with the territory sometimes. The 'new guy' needs to realize it won't always be code slinging or new development. Sometimes it is maintenance coding - much of the time it is. Sometimes it is 'turn the crank' type work. Sometimes it is report writing.
A good manager or senior developer will mentor the new hire. If a shop doesn't do that, I'd probably not want to work there myself.
They should be pair programming (or spectator programming) with different people from their department for a few weeks. Then they get to know all the people, the structure, the code and useful tips.
Reports are a wonderful introduction.
They tend to have very specific specifications, unlike many other projects. They're a good "stand alone" task. They also give the developer a good introduction to the domain model, which they must use to actually get the data out for the report.
Finally, they're (typically) reasonably simple with some reporting framework doing most of the heavy lifting for them. So they need to focus on learning the tools of the trade, deployment, and the data model.
They're a nice gradual introduction to the larger domain and application.
I've never been put on a non-important job as a safety function. Even when I didn't know exactly what I was doing I got put on important projects people wanted yesterday, and then paired with someone who had specific development he/she wanted to offload onto the new-hire.
It works pretty well that way.
If you put a college grad on report-writing duty for a long time, he's going to bail on you. Bad management and a waste of money...
I have two contrasting experiences with Crystal Reports in two different companies:
With my first employer (fresh out of University), our Crystal Reports expert was leaving, so I was asked to take over the role. No actual training was provided, so I had to learn everything on-the-job, with no support from either the Vendor or the Employer. Although my position description was as an IT Developer, I eventually spent 100% of my time working on Crystal Reports. It was an unproductive experience for me, and a waste of manpower and resources.
My current employer asked me to assist another Developer in creating and maintaining their Crystal Reports setup. Because they provided adequate training, and I was mentored in the role, I gained knowledge on multiple systems and databases. I even a little experience at administrating and maintaining SQL Server. And I also got the chance to interact with many different clients in the company, as many different sections of the company needed these reports.
So my answer to the original question is that it really depends on the organization, rather than the central concept. If your employer is intending to use it as a way of familiarizing new employees with multiple systems, then I think it's a great idea. If it's just a short-term way of foisting a thankless (and rotten) job on a hapless new employee, then I think it's a waste of manpower and resources.
The good thing about reports is that they are not updating information so there's no chance that any data will be lost.
Depending on what the tools are for reporting too. When I did reporting, I learned tons about SQL, and stored procedures. Of course that is probably not the norm for reporting.
It depends on the report, and it depends on the job. Many reports are anything but trivial, and excellent SQL skills are needed to create a performant and properly maintainable back-end. If your newbies are good with SQL, let them cut their teeth on the queries. It will be a good way for them to learn the schema of your database.
However, if "putting them on reports" is just a euphamism for them trying in vain for hours without direction or inspiration to format a table in Crystal reports 25 (or whatever the current version is), well, I think you probably already know my answer to that question...