Coding is hard, let's go shopping!
-
I think he meant access to complete documentation. Aka source code.
-
There's no learning curve. There's a cliff. And if you're at the bottom, good fucking luck learning how to climb up it.
There is no such thing. It is maybe a long trail, and anyone who can learn to code can walk the path. There are actually many paths, each going to a fairly unique peak and depending on how you jump from technology to technology and job to job you end up on one of them. Or like a train that rides on a Markov chain track, certainly not a cliff
-
If she did the same in 2014, she'd just be sneered at by more "technical" people who would bitch that she should be using a "real" database product instead of building it herself, and what was she thinking, and now this is going to be a huge mess they have to clean up, and etc.
"Back 1-2 million years ago, if a human went out and built a fire to solve their freezing problem they'd be applauded by nearly everyone. But now, if you build a fire in the middle of the office, the more "technical" people who would bitch that she should be using a "real" heating product instead of building it herself, and what was she thinking, and now this is going to be a huge mess they have to clean up, and etc."
Point is, a lot of that stuff is not as good as what we have now. Our technological capabilities have exploded, but the technologies themselves can also be considered more "advanced." If Janice builds an Access database and uses it properly now, then I'll applaud her. If she tries to replace what should be an instance of MySQL with an Access database, then no shit am I going to sneer.
-
No, I meant quality documentation, like
but source code is another kind of documentation, when all else fails.
-
Which smells more of professional megalomania than any reasonable argument.
Speaking of which, one of the comments points out that the fizzbuzz study was retracted, because:
Though it’s embarrassing, I feel it’s necessary to explain how and why I came to write “The camel has two humps” and its part-retraction in (Bornat et al., 2008). It’s in part a mental health story. In autumn 2005 I became clinically depressed. My physician put me on the then-standard treatment for depression, an SSRI. But she wasn’t aware that for some people an SSRI doesn’t gently treat depression, it puts them on the ceiling. I took the SSRI for three months, by which time I was grandiose, extremely self-righteous and very combative – myself turned up to one hundred and eleven. I did a number of very silly things whilst on the SSRI and some more in the immediate aftermath, amongst them writing “The camel has two humps”. I’m fairly sure that I believed, at the time, that there were people who couldn’t learn to program and that Dehnadi had proved it. Perhaps I wanted to believe it because it would explain why I’d so often failed to teach them. The paper doesn’t exactly make that claim, but it comes pretty close. It was an absurd claim because I didn’t have the extraordinary evidence needed to support it. I no longer believe it’s true.
So yeah, actual megalomania probably contributed (indirectly) to that claim.
They could, but the industry no longer makes tools for people who want to do that
Like what? Serious question here - I've seen what seem like learner-level toy languages and stuff even these days, but I was only 6 in 1992 so I don't really have an idea of what you're comparing 'now' against.
Look, if Janice in 1994 built an Access or Filemaker database to solve her problem and save her own effort, she'd be applauded for it by pretty much everybody involved.
If she did the same in 2014, she'd just be sneered at by more "technical" people who would bitch that she should be using a "real" database product instead of building it herself, and what was she thinking, and now this is going to be a huge mess they have to clean up, and etc.
Ah, yes. I hadn't thought about it from that direction. So you don't mean the tools, but rather the attitude surrounding them, which requires a cultural fix and/or making it easier to use the 'professional' grade tools so that even the novices/amateurs can use them easily for their purposes.
Do you think that the sentiment expressed in that one xkcd comic ("You're one of today's lucky 10,000") is something like what you'd like to see the industry move towards culturally?
If a user doing development in Access create a spaghetti mess, that's nothing but evidence that Access needs improvement. The problem isn't with the user, who charged forward with the tool in good-faith, the problem is with the tool, which didn't not assist the user enough in creating what they actually wanted.
So very, very true. Adobe Photoshop has a nice feature that makes it somewhat easy to script actions - even ones that require user intervention at points - and this is something expected to be used by professional artists. And it is because it has a decent level of usability. Same goes for Adobe Lightroom which has a way to basically make custom database views based on arbitrary combinations of parameters and metadata. Access? I'm (obviously, since I'm here) a CS oriented person, and I'd rather write SQL than use that (same for its OO.org/LibreOffice equivalent) — but I'm not the target audience, and it's got a more convenient UI for the typical user than setting up a database server and programming against it in $language with $gui_framework would be.
There are other ways to allow people to make scripts and such than requiring them to write text-based code, and in many cases that's exactly what should be done.
I'd even go as far as saying that programming being a "profession" instead of just "a skill some guys have" is a bad idea.
Because if you put someone who does programming as a profession in charge of a product, they'll just make something that's only useful to people who do programming as a profession.
I don't agree with this, however. Programming is engineering, and it's not a bad idea to have it professionalized in similar ways. But I do have some qualifications on that:
- It needs to have a greater focus on design and usability with regards to the UI. My impression is that this is getting better, but software development still doesn't seem to have the commonly expected end-product usability as common household non-computing products (which are also engineered).
- Not everything needs a full professional to be involved, just like you don't necessarily need a professional accountant to do your personal taxes and budget. Programming should be accessible, even if bigger or riskier projects are still usually best left to professionals.
I'm mostly with you in spirit, but I disagree that spaghetti code is evidence that "Access needs improvement." (It needs improvement for other reasons, and that's why things like Postgres and Oracle and MSSQL exist) You can make spaghetti with any language, even C# or ANSI SQL.
See my comments above about what you can do with some Adobe stuff - just because crap code can be made in any language doesn't mean that consumer-targeted scripting tools need to make it easy (or even have a user-visible language). That spaghetti code is an easy and obvious thing to do in Access means its interface sucks, given the target population. It's not so much a problem for C# and such because the target population is expected to have a different skill level and know not just to avoid that stuff, but how to do so well.
certainly not a cliff
It bears quite a strong resemblance to a cliff if you're starting with NFC and have to get something done now.
If Janice builds an Access database and uses it properly now, then I'll applaud her. If she tries to replace what should be an instance of MySQL with an Access database, then no shit am I going to sneer.
Why? If she doesn't know/realize there's a better way with little added cost, and this is the only tool at hand, it'd make sense for her to at least try it and then ask for help once she realizes it's beyond what the tools she has available can reasonably do for her. Beyond that, shouldn't it be easier for her to start closer to the better way in the first place? Like having a tool that can interface with a proper database server with the same relative ease of design/prototyping as Access?
###Examples:
Adobe Lightroom smart collections interface:
Adobe Photoshop actions:
Look at that! Two programming-type things without a line of code in the UI! It's like it's actually possible to make things easy for consumers to work with in a programmatic way.
-
The point is this: you can make the right thing easy, and you can make the wrong thing difficult, and you can make refactoring from the wrong thing to the right thing possible.
No. I have seriously seen things that are beyond repair, especially when it involves past data that's simply not collected.There were a home-built accounting system that mixed a few accounts, so the balance sheet never be able to match. And we have to assume the old closing balance is correct and use it as raw opening data in order to resume "reconstruction".
The problematic past data gone to "archive database" and is isolated from the new system, they only avaliable in some selected read-only view with bright red warning that there could be inconsistant data and use with caution.
-
It's this methodical approach to problems which I think cannot really be taught.
I don't know if it can or can't, or whether (like with languages) there's a window of opportunity during childhood when many people can learn but after which it gets progressively more difficult, but many people have definitely never been taught it.
I suspect that we should differentiate between teaching people to be amateurs and teaching them to be professionals. With the teaching of amateurs, we're talking about getting people to be somewhat productive and to stop using the equivalent of empty bottles and old shoes to hammer in nails. With professionals, they need to be much more organised and have much more rigorous training; a professional needs to care about scalability, performance and maintainability, and that means they need at least a passing familiarity with quite a bit of much more complex material than amateurs ever need to care about.
-
Programming is engineering
It's not really. Software Engineering is engineering. Or do you consider electricians engineers? You can do maintenance on electical installations without having the skills needed to plan the wiring for a building, or a car. There are plenty of programmers, usually self-taught, that cannot engineer software to save their lives. Programming is a single skill in the Software Engineer toolkit.
-
I tried to google something about Microsoft Lightswitch and found out it's almost dead.
-
Same goes for literacy, math, etc. You could even add basic computer skills to this list, although that's less and less relevant with the move towards dumbed down phones/tablets.
That's definitely not the case for programming, though. This whole "anyone should learn to code!" movement is bullshit.
You know who else doesn't want people to learn to code? Jeff Atwood. You know why? Because non-programmers think Discourse is a good product.
Truth is, even if the noobs don't learn how to actually write good code, there's a whole hell of a lot they could learn about how to appreciate good code. And if you ever want to be able to use a quality product again, or hit a helpdesk that could stand a snowball's chance of solving your problem, maybe encouraging the general public to pick up the kind of skills that you like to use would be the way to go.
I have seen the kind of code that “developers are the most important people at this company” produces, and it is fucking horrendous. Asking users to upload an image file, copy the link, paste it into a text box containing the text
<img src="PLACEHOLDER">, and if they fuck it up (of course they're gonna fuck it up — they're users, not coders, do you think a coder would ever stand for that shit)? Incomprehensible stack trace in another part of the product.Far better to be a dumbass who actually listens to what customers and management want, and maintains their code, than a cowboy who is untouchable because he hacked together some shiny new feature that everyone wanted.
Even if not everyone can be a doctor, anyone can be a nurse. Sharing programming knowledge is good for everyone.
-
No. I have seriously seen things that are beyond repair, especially when it involves past data that's simply not collected.
There were a home-built accounting system that mixed a few accounts, so the balance sheet never be able to match.
Not everything needs to be amazingly perfect. There are many tasks which are simple and should be easily accomplished with rudimentary programming knowledge.
To borrow a carpentry example:
If I so wanted, I can go out and learn to make a table.
This is possible because of carpentry's low barrier to entry: at its absolute simplest, you can line up some wood and screw it together with a power drill.
It won't be a very good table, but it doesn't need much to be a table: It's a flat surface above the ground that you can put stuff on.
Entire accounting systems, on the other hand, are more like a house. Anyone who builds them without knowing what they are doing are way out of their depth. That's the point where you either learn a lot more about what you're doing, or hire someone who does.
-
I have seen the kind of code that “developers are the most important people at this company” produces, and it is fucking horrendous.
Reminds me of this monstrosity which someone pitched as an alternative to opening Notepad.
-
Software Engineering is engineering.
I was being really loose with the term since I didn't feel like doing a back and forth to figure out which variety of meaning was intended. My point was intended to be similar to what you said, with the software engineer being in the professional set.
-
Even if not everyone can be a doctor, anyone can be a nurse. Sharing programming knowledge is good for everyone.
You know what? As usual, I have no idea what you're even arguing.
Anyone can learn more stuff? Sure.
Would a world be a better place if everyone knew the basics of programming, car maintenance, nursery and a hundred different things? Of course.
Should managers understand the technology they are in charge of and keep cowboy coders in check? Duh.
How all these tie together is less clear, though.
-
Programming is a single skill in the Software Engineer toolkit
That reminds me of an old question be asked to discuss at O'Camp.You need to learn a language well enough to do translation job, just that simply proficient at grammar of a language does not make you great writer.
You need to learn a programming language well enough to translation specification to software that can run, but simply proficient at language structs does not make you great software architect.
Compare and contrast.
-
Should managers understand the technology they are in charge of and keep cowboy coders in check? Duh.
The advice I gave my brother (an accountant who was moving into management) a few years ago was this: be able to read what your people do with code, but don't fuss too hard about being able to write it. The problem isn't one of whether people should learn to write programs, the problem is that there's not enough time in this life to do everything.
Those of you with “reincarnation” season tickets can learn as many skills as you want.
-
Should managers understand the technology they are in charge of and keep cowboy coders in check? Duh.
Manager are usually the ones that will put me over a horse and give me a hat
-
If that code is unmaintainable or delicate, that calls for better VBA-like tools, or maybe a product with more useful help.
This means either a Holy Grail of programming languages which is very easy to pick up and has magical properties that make every user follow all the idioms there are, ensuring it would never become unmaintainable, or a custom-tailored tool that solves exactly the problem they have at hand. Guess what - the industry has been doing one of these two since the very beginning!Besides, I've seen plenty of professional software developers write code worse than the worst VBA monstrosities. There's no monopoly on spaghetti code here.
There are people who can't code well, there are people who can code well, and inbetween these two, there are people who can code well enough to pass the interview and not be let go for a few months/years, but not enough to be actually able to write code that doesn't become #1 position on the list of things to rewrite from scratch the very moment it lands in repo.The problem is, all of those tools (at least since the long lamented HyperCard, and the first few generations of Access and FileMaker) are firmly in the control of developers who think the general public has no business being developers. So they never bothered to improve those products in the correct way.
I would agree with you, if only what you're saying was true. You have the right attitude, but sadly, you seem to forget that every single initiative to make programming tools more accessible to general public (and boy, there were just too many of them) ended badly - either the product became forgotten, or the professional programmers who could deal just fine with C++ are now forced to work with some abomination like Rhapsody.The hard part about programming isn't making your tool do the right thing. It's knowing what the right thing is.
-
The hard part about programming isn't making your tool do the right thing. It's knowing what the right thing is.
For hitting machine with hammer: $0.05
For knowing where to hit machine with hammer: $999.95
-
every single initiative to make programming tools more accessible to general public (and boy, there were just too many of them) ended badly
COBOL.
End of argument.
-
There's a good chance that if you hit the machine 1000 times, one of them is going to work.
-
There's a good chance that if you hit the machine 1000 times, one of them is going to work.
Next time you have a bug, get a hammer and hit your computer 1000 times.
-
There's a good chance that if you hit the machine 1000 times, one of them is going to work
...and that's the one whose owner you submit your invoice to.
-
And C# is a lot easier than COBOL to do the same stuff. But now users wan't it on the web, and to run in all that incompatible browsers, and they expect a lot more from the UI.
What seems to be the discussion here is that tools that sacrifice the possibility of doing the hard stuff to make the easy stuff easier. But when you need to do something hard with them it's always a pain.
-
No, I meant quality documentation, like
You are probably the only one in the universe, INCLUDING HUGE OPEN SOURCE FANS, who thinks one of the goals of open source is to improve the quality of software documentation.
-
if Janice in 1994 built an Access or Filemaker database ... she'd be applauded for it by pretty much everybody involved.
If she did the same in 2014 .. sneered at by more "technical" people ... using a "real" database product instead of building it herself, ... going to be a huge mess they have to clean up, and etc.
If someone takes the initiative to do this when there is no other way, yes she should be applauded for it. Still doesn't make it the best case scenario though.
If a user doing development in Access create a spaghetti mess, that's nothing but evidence that Access needs improvement. The problem isn't with the user, who charged forward with the tool in good-faith, the problem is with the tool, which didn't not assist the user enough in creating what they actually wanted.
Spaghetti messes are an inevitable outcome of the amateur programming/development process. We've all made spaghetti messes. Some of the worst of mine came in Excel VBA.
This is by NO means a sign of the software their using needing improvement, but the user of said software needing to improve their skill set, if they should choose.
The problem is, all of those tools (at least since the long lamented HyperCard, and the first few generations of Access and FileMaker) are firmly in the control of developers who think the general public has no business being developers. So they never bothered to improve those products in the correct way.
Wrong. These tools were developed to fit a niche gap for non-developers, or non-database admins to get the job done. They fit that role exceptionally well, which in turn has given this generation atrocious technical debt. Hence probably the over-correction of attitude by us today of "BURN IT TO THE GROUND!" (of which, i am definitely guilty of, mainly because of the systems I've had to support b/c of this attitude)
As a natural consequence, as our complexity increases so should the complexity of our tooling. It is just the natural course of things. You can't make a program like access fit all use cases. Doing such would be trying to engineer a better hammer because people think screwdrivers are too hard.
That being said, I for one am all for enabling access to educational tools for programming. We, as an industry, just need to do a better job of cultivating the skilled and exceptional, while helping the less skilled fill vital roles as well.
-
Ah, yes. I hadn't thought about it from that direction. So you don't mean the tools, but rather the attitude surrounding them, which requires a cultural fix and/or making it easier to use the 'professional' grade tools so that even the novices/amateurs can use them easily for their purposes.
No, I mean both. The two are not mutually-exclusive.
Access hasn't improved since around 1997. But also, now professional programmers are complete assholes to non-programmers trying to "muscle in on their turf" or whatever.
Do you think that the sentiment expressed in that one xkcd comic ("You're one of today's lucky 10,000") is something like what you'd like to see the industry move towards culturally?
I guess it's an ok attitude to have.
All I really want is for programmers to have the notion that computers exist to empower people and make their lives easier, and if there's something in the computer that's making that difficult, then let's get in there and fix it.
So very, very true. Adobe Photoshop has a nice feature that makes it somewhat easy to script actions - even ones that require user intervention at points - and this is something expected to be used by professional artists.
That's because it was originally a Mac Classic application, and they got all that functionality "for free" from AppleScript. Originally.
Another great example is Unreal Engine's "blueprints" feature. Which is powerful enough that you can easily code an entire game without ever typing a line in UnrealC.
So the stuff's kind of still out there, but it's super rare.
Access? I'm (obviously, since I'm here) a CS oriented person, and I'd rather write SQL than use that (same for its OO.org/LibreOffice equivalent) — but I'm not the target audience, and it's got a more convenient UI for the typical user than setting up a database server and programming against it in $language with $gui_framework would be.
People keep missing the point on Access. The point of Access is to make applications, not query databases. Saying that you can replace or replicate it with MySQL is extremely misleading, because MySQL (or MS SQL or Postgres or whatever) has no facility for making applications. All they do is let you query databases.
There are other ways to allow people to make scripts and such than requiring them to write text-based code, and in many cases that's exactly what should be done.
Right; but there's also nothing wrong with text-based code. Don't get single-sighted. HyperCard and AppleScript both had a very effective and usable text-based code backing their behaviors.
It needs to have a greater focus on design and usability with regards to the UI. My impression is that this is getting better,
Wow I can tell you weren't around in 1992. Jesus.
Like having a tool that can interface with a proper database server with the same relative ease of design/prototyping as Access?
That's not a bad idea, but remember part of the pain that Access removes is the pain of installing/configuring a database server. (And actually, Access already has this feature-- it can connect via. ODBC to any database back-end that's reasonably SQL-ish. But setting up ODBC connections is also hard as fuck, natch.)
-
No. I have seriously seen things that are beyond repair, especially when it involves past data that's simply not collected.
So have I. I've seen it from professional developers.
What's your fucking point? That nobody gets it perfect the first time? Great. but: duh.
-
Some skills are necessary for anyone to learn, whether they have the talent or not (eg. driving).
It's almost 32 years I tread the planet, and I don't have a driver's license.
Also, I have difficulties operating a microwave that has a UI more complex than two knobs for "power" and "time".But hey, I can cook, I can design a program and code it, so that's... that's something.
-
You know who else doesn't want people to learn to code? Jeff Atwood. You know why? Because non-programmers think Discourse is a good product.
AND SOME PROGRAMMERS DO!
That is another huge problem that I've griped about frequently.
And it's awful because it contributes to that "computers are just weird scary boxes" feeling. "Why when I scroll up one post on Discourse, the scroll jumps up like 37 posts?" Sure you or I could say, "well obviously they are firing a onScroll event handler a bunch of times when they should only be firing it once", but the average user just shrugs and goes, "nothing on the web ever works right anyway."
Which is correct, but it's not like it doesn't work right because God ordained it; it doesn't work right because Jeff Atwood and his goon-squad are too fucking lazy to fix the bug!
I have seen the kind of code that “developers are the most important people at this company” produces, and it is fucking horrendous.
That's called Google.
Buzz, Wave-- disasters. Google+-- disaster covered-up by literally forcing people on YouTube to use it. Other than Gmail (which is just passable), Google's never home-grown a product worth using.
Why? Because they hire developers based on who can solve complicated math equations on billboards.
Entire accounting systems, on the other hand, are more like a house. Anyone who builds them without knowing what they are doing are way out of their depth. That's the point where you either learn a lot more about what you're doing, or hire someone who does.
While that's true, 95% of the stuff you need to know to do it correctly is about double-entry accounting and GAAP, not about software engineering.
I currently write software in C# to handle health insurance enrollments. Since I've been here, I've had to learn very little new C#, but I've had to spend hours and hours and hours, probably 50% or more of my time, learning about how health insurance works.
That's why I'm not sure about software being a "profession" among anybody outside of Apple or Microsoft writing OS kernals. To write software that does X, you need to know a fuckload more about X than you need to know about software. You know who already knows a fuckload about X? The people you're writing the software for. If only those giant software brains at Google could just figure out how those people could write software themselves...
-
This means either a Holy Grail of programming languages which is very easy to pick up and has magical properties that make every user follow all the idioms there are, ensuring it would never become unmaintainable,
I JUST called out someone yesterday for pulling this exact same bullshit. Fuck off.
-
People keep missing the point on Access. The point of Access is to make applications, not query databases. Saying that you can replace or replicate it with MySQL is extremely misleading, because MySQL (or MS SQL or Postgres or whatever) has no facility for making applications. All they do is let you query databases.
Back in my younger days temping in offices to pay for my drinking habit this was how we used access. Using access to house data was secondary to generating reports and calculations on the data. You could pay a software house to do those things for you but by in large it was cheaper to write something quick and dirty rather than fork out thousands on software engineers. 90% of time it's actually okay.But hey, I can cook, I can design a program and code it, so that's... that's something.
And how will that help when the zombies start banging at the door.
-
So the stuff's kind of still out there, but it's super rare.
The main problem with that sort of system is that it takes a lot of work to make. It's a justifiable amount of effort in some circumstances, sure, but unless you want to restrict the areas that most people get work done in to a few domains blessed by the high priesthood who create the GUIs, there are other approaches that are more sensible in practice.
Especially when it's pretty simple to do something that delivers almost the same resulting effect (programmability) with a fraction of the effort provided you drop doing the fancy GUI.
-
The main problem with that sort of system is that it takes a lot of work to make.
The
#duh
heard around the world!
-
That's called Google.
Buzz, Wave-- disasters. Google+-- disaster covered-up by literally forcing people on YouTube to use it. Other than Gmail (which is just passable), Google's never home-grown a product worth using.
Why? Because they hire developers based on who can solve complicated math equations on billboards.
...And those developers are notorious for shrugging off any notion of how anything in the real world works.
I still don't know what kind of itch it was that the Buzz and Wave were supposed to scratch. Messaging platforms are a dime a dozen, and it was like that back in 2009-2012 when Wave and Buzz were struggling to gather some hype.(I still prefer G+ over Facebook. Facebook is much shittier on many levels.)
-
To write software that does X, you need to know a fuckload more about X than you need to know about software.
I'm entirely unconvinced that a competent domain X specialist with no software engineering skills would agree with you. Because if you were right, I would expect the result of you spending enough hours in the company of an expert health insurance enrollment colleague to be able to write bug-free, maintainable, to-spec health insurance enrollment software would result in the creation of two people capable of doing that. But I'll bet you only end up with one.
That whole ten thousand hours to mastery thing applies to software construction every bit as much as it applies to double-entry accounting and GAAP.
-
writing bug-free, maintainable health insurance enrollment software.
Can I just say one more time that you people are REALLY overestimating the competence of the average software developer.
-
I still prefer G+ over Facebook. Facebook is much shittier on many levels.
And Betamax was easily a better tape cartridge format than VHS. But everybody used VHS because that's what everybody used.
-
The
#duh
heard around the world!
Nice one, Drax!
https://media.licdn.com/mpr/mpr/shrinknp_800_800/p/1/005/0b0/106/340dc15.png
-
And Betamax was easily a better tape cartridge format than VHS. But everybody used VHS because that's what everybody used.
Well, the humanity is often fucked with things like this.
-
Can I just say one more time that you people are REALLY overestimating the competence of the average software developer.
Developer incompetence does not strike me as a phenomenon capable of being overcome with better tools.
[quote=Charles Babbage (1791-1871)]On two occasions, I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able to rightly apprehend the kind of confusion of ideas that could provoke such a question.[/quote]
-
That's because it was originally a Mac Classic application, and they got all that functionality "for free" from AppleScript. Originally.
From what little I know about AppleScript (and I know only as much as you said in your earlier posts, because you're the only person in the whole world I ever heard talking about AppleScript), the application developers need to put hell lot of work to make AppleScript actually usable with their particular app.Another great example is Unreal Engine's "blueprints" feature. Which is powerful enough that you can easily code an entire game without ever typing a line in UnrealC.
If this game is Doom. For anything more complicated, blueprints are there to just bind your UnrealC scripts with objects inside editor. Which means 95% of your game logic needs to be written in actual programming language.
-
Agreed. Especially the final paragraph.
-
I JUST called out someone yesterday for pulling this exact same bullshit. Fuck off.
No, that person's post was slightly different. In particular, there were no common parts except we were both replying to you.
-
No, that person's post was slightly different. In particular, there were no common parts except we were both replying to you.
No common parts except we were both interfering with blakey's crazy ideology circlejerk.
-
There is so much misguided attempts in the industry.
It's non-sense to have accounting systems built by team(?) of people who apparently is weak on accounting concept, and without seeking advice from who have an idea on the topic (like a BA).
I think if there's old saying that "you learn concept in the school, and then learn your tools at your job", maybe the CS courses will make more sense to be double degree to other subjects, so at least these people can code (or lead to code) what they understand.
-
No common parts except we were both interfering with blakey's crazy ideology circlejerk.
Isn't that what I just said?
-
Another example: OBIEE. the interface is slow and terrible, but it lets ordinary business users query data in complex, interesting ways without writing a line of SQL. I've even seen them use the XML export feature without having any understanding of what XML is or how it works or where it came from -- they just export the XML, email it to another person, and now that person has a copy of their complex query "like magic". I attended an accelerator session on how to use Excel to make a template for the report output so it looks exactly pretty, with the right header graphics and branding. All given by people who don't program, don't understand SQL or databases, have no idea what software engineering is about -- they just need data in reports tomorrow.
-
I am sure HR here think we are replaceable with anyone with a similar education and that it wouldnt have any impact if they didnt it once a month. we're commodity now in their heads.
-
Fortunately, we're capable of replacing virtually all of HR with a small shell script.
