|
DerekTP123 wrote: However I'd still contest that letting end-users - even with reasonable SQL skills - loose on writing Stored Procs is a bad idea.
And then MS Access was introduced, lowering the required skillset to manipulate data in SQL Server. Look at me, I clicked together a delete-query!
Why does it say "no records found" when I run it again?
DerekTP123 wrote: I've experienced places where "[the application developer] will have to use the structure as determined by the DBA" has caused not only poorly-performing apps
So? My first guess is an incompetent DBA - they usually know more about performance in a DB-environment than me. SQL Server in particular has these statistics that it gathers, and a good DBA will explain the cost of every word in your query.
DerekTP123 wrote: Too much delineation between roles, lack of communication, inflexibility and "empire-building" is never good.
Empire building? This isn't politics, but a definition of roles, and a delineation of profession. I do not go into the kitchen in the restaurant, regardless of politics - it is not my profession, and though I can cook, I really shouldn't do so in a professional environment.
DerekTP123 wrote: Development involves ongoing negotiation
In over 20 years, I never negotiated. Sales negotiates, my boss does.
The person responsible for the data-integrity and the servers performance is the one who determines how the data is stored. If you as a dev need it in another format, the DBA will provide you with an appropriate view, or generate a temp-table.
How many programmers can explain the different locking-mechanisms? How many can explain a clustered index? Most that I know don't even care about a primary key - they'll add an autonumber or GUID and be done with it.
DerekTP123 wrote: a new app with a unique access pattern
Having a DB means you are following a standard in how to store data. That's hardly unique, no matter how important you think your product is. If you use an RDBMS, you follow the rules of the DBA, because a DBA is trained for exactly that.
DerekTP123 wrote: collaboration
I never done that either; I'll listen to what the client needs, then I'll explain the client how I will implement a solution. Simple example that runs parallel to the DBA-discussion - lots of clients will want a word on how the UI looks. None of those will have had any training with respects to UI-development, and don't know sh*t about accessability-features. So no, I will create a UI that I think is required, not what the client thinks that is needed.
Arrogant? No, not at all. Walk into the restaurant of a kitchen, try to collaborate and negotiate a fried egg with the chef. You'll be out of the kitchen before you can start a discussion, because they have work to do. And no, your eggs aren't that unique 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
MS-Access - exactly my point. Just cos an end-user wrote a query against a table in Access doesn't mean they should be let loose writing SPs against the corporate database.
Incompetent DBA? No, just a DBA that has not been properly involved in the applications' development. You seem to feel there's one single solution to any given data structure, without taking into account the use cases against that data. A design that might allow for lightning fast single-row updates might be a complete dog when running summary reports. If you allow the DBA to dictate the *only* possible structure without proper liaison you end up with inappropriate solutions.
Empire building - in your example, that would be the chef telling the customer what they were going to have for dinner. The customer wants a vegan salad, they get served a rare steak - not a great outcome.
"I never negotiated". All of life is a negotiation. What I mean by negotiation is a sharing of needs - requirements - which may be an iterative process until both parties are fully satisfied they understand the other's position. As for locking mechanisms etc - exactly, a lot of programmers neither know, nor appear to care, what havoc their procs wreaks on other applications or even their own. And you expect an end-user to knock up a SP as though it were a macro??
By "unique access pattern", I don't mean globally unique. I just mean doing something with that database that hasn't been done before. Your solution is for the DBA to provide a new view or temp table. That may be the right solution, or it might be something more "radical". Either way, it involves the DBA and is often not something the "end user" can resolve by themselves.
As for never collaborating, well done on having a career that involved zero teamwork. I've been freelancing a quarter century now, and it's all been about collaborating. A good software developer doesn't just sit hunched over a terminal, they are involved with people - end users, DBAs, graphic designers, hardware planners etc.. There are ways to tell a client that what they're asking for is the wrong thing, but the best way is always for the client to come to that conclusion themselves. Collaboration and negotiation are the "soft skills" that the IT industry is finally waking up to realising are as important as technical ability.
Anyway we've wandered a long way from the OP's original question! If they're still following this, though, maybe it will give them some food for thought... if only that there's more to this development thingy than meets the eye 
|
|
|
|
|
DerekTP123 wrote: taking into account the use cases against that data. A design that might allow for lightning fast single-row updates might be a complete dog when running summary reports.
Incompetent DBA and incompetent developer. A DB is designed to be optimized for speed, so "lightning fast" has no meaning there; it a consultants term. One can also simply export-copy a part of the DB for reporting 
DerekTP123 wrote: If you allow the DBA to dictate the *only* possible structure without proper liaison you end up with inappropriate solutions.
The DBA owns the server and the data. If he doesn't, he cannot guarantee consistency of the data. How many of the other people involved have done the DBA's training? Where does the arrogance come from to explain the DBA how he/she should do their work? If the work is so simple as you explain, you don't need anyone with an education - since you know it better anyway!
What happens in practice is that the DBA caves in to threats and continous whining, delivers something that he doesn't fully support, and leaves before the sh*t hits the fan. You don't tell the cook how to cook, you don't tell the DBA how to administer his database.
DerekTP123 wrote: Empire building - in your example, that would be the chef telling the customer what they were going to have for dinner. The customer wants a vegan salad, they get served a rare steak - not a great outcome.
Hahaha, most costumers will not accept that, but that hardly requires negotiations in the kitchen. Once you place your order, negotiations are over.
DerekTP123 wrote:
"I never negotiated". All of life is a negotiation.
Ah, so now we use philosophy to justify the extra talking? How about biology, as everything we do is related to sex? All life is about sex, not negotiating sex.
I write code, and do not negotiate. Never have in what's now nearly 25 years of work. The idiots that keep on negotiating are usually the projects that fail. There's a problem-statement, there's specs, there's a way to turn specs into code.
DerekTP123 wrote: I just mean doing something with that database that hasn't been done before.
There's nothing that hasn't been done before with databases. Your ideas aren't that unique, as I already explained.
DerekTP123 wrote: ollaboration and negotiation are the "soft skills" that the IT industry is finally waking up to realising are as important as technical ability.
Collaboration is a bullshit term. Devs work in project teams, and collaboration is nothing new for them. We will even work with people we never seen. Lots of Open Source to prove exactly that.
Negotiations aren't a dev-skill either. Yes, a recruiter will wet their pants when reading those words. Also, the project-team has a sprint to do, and the project-lead should kick your negotiating arse out too - there's a price on what has been agreed, and the lead should not renegotiate.
DerekTP123 wrote: A good software developer doesn't just sit hunched over a terminal, they are involved with people - end users, DBAs, graphic designers, hardware planners etc..
That's not a developer. We don't need to talk to everyone, because there are specs. The graphics designer is ignored a thousandfold, as I determine how the UI will work.
We also do not disturb the people who make hardware; if we need to work together, we'll talk about and define an interface. Last thing we need is more politics in IT, there's already too many people that talk alot, cause more confusion, and do not bring any added value to the table.
..and before you state I lack the soft skills; I'm rather good at it. Might be due to the fact that we never had "collaboration" and "negotiation" in our schooling, but things like "working in a project" and are good enough at our work that we need not hide in countless meetings that lead nowhere.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: before you state I lack the soft skills; I'm rather good at it.
 so much so that you've repeatedly failed to read and understand my comments, including my hint at the end of my last post it was a time to draw a line underneath this sub-thread.
I congratulate you on a most apt signature line.
Cheers and goodbye.
|
|
|
|
|
DerekTP123 wrote: so much so that you've repeatedly failed to read and understand my comments, including my hint at the end of my last post it was a time to draw a line underneath this sub-thread.
No, disagreeing does not mean I don't understand your petty point of view.
DerekTP123 wrote:
I congratulate you on a most apt signature line.
Thank you. A convenient way for you to get out while you can.
DerekTP123 wrote:
Cheers and goodbye.
Cheer
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I do not think that anyone will hire you after 3 month - intensive as be - learning...
You say that you are "pretty good with computers generally", but on what level? My mother mastered blogging in two week (started at age 65), but it doesn't mean that she can program a blogging software...
I would take an easy - half time? - job to keep money in balance a bit, but to left time for some serious research...
First step I would recommend is to find a small challenge and check if you can do it without any help, just doing your research on your own - if you find all the messing around with the unknown, it is probably for you and you can look for something to learn...
As you have not much time to stat actual work, I would look into the current job list around you and aim for one of those - like front-end-for-the-web...
Learn it well - apply for a job - and continue to learn while you are working...
All of those are serious about it learn every day of every week, it does not work without it - you have been warned!!!
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
The first piece of advice I will give is never listen to any advice including my own, which is why I won't be giving you advice
But I think I can offer you encouragement.
Having come from architecture I think you are in a very good position. I am going to make a guess that maths plays a fairly big part in your previous training and work. If that is the case you are at a distinct advantage.
I am one of those who struggles a bit at maths. As a 49 year old developer who works with younger developers far more talented than me when it comes to writing code, I have noticed those developers with a solid maths background are always those who are the best at pure programming and solving problems.
Fortunately for me there is more to being a developer than just banging out code, which is why I have managed to find a place in the industry.
However I am going to say that you are at an advantage in having come from an engineering background.
Could you be a developer in 3 months?
Maybe, it depends on how fast you learn and how well you will be able to persuade a prospective employer to hire you.
I would not however recommend going into software development to make money - you are never going to be paid for all those hours you put in outside of work, it's really more of a lifetime commitment than a job.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Start small - Eddie is right that a lot of the "boot camp" experiences are a rip off.
You could start for free to see if it makes any sense to you; if you mind works the right way.
Go here: Downloads | IDE, Code, & Team Foundation Server | Visual Studio[^] and grab a copy of the Community Edition (older versions than 2019 are available via the "older versions" link on that page if your hardware is relatively limited) - it's free and complete, as well as being the best IDE on the planet.
Then go here: .NET Book Zero by Charles Petzold[^] and grab a copy of the book.
Now start reading, and see if you can understand it. If you can, then it's worth considering a career in software. If you can't ...
Getting that job though; that'll be the hard part. Experience counts in this business - just as it does in architecture - so getting the first job may be a struggle.
Whatever happens, good luck - I hope it all works out for you.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
A few months is a short period... Especially when all you're doing is learning.
You'll really start learning out in the field.
Anyway, you'll need to get some basics covered before anyone would even consider hiring you.
Get some certificates to assess and prove your skills.
Also very good, write some blog posts to show you're really into it.
I'd apply for a junior job with low pay and then work your way up, then switch jobs and get paid what you're actually worth by that time (which is usually a lot more than you get from an intern/junior position).
Good programmers are hard to find, so the people willing to learn should get a chance.
I started working in IT from scratch, no previous experience.
I had a little help as my uncle bought my dad's company and so I could work there because of my connections.
After about half a year I became lead developer, which really says more about the skills of the company than about me.
Then again, I spent 8-9 hours programming on the job, I had a mentor, and I continued at home for another 4-5 hours every evening (I was still living at home and I had only a few minutes commute).
It's possible, but not easy and you need a bit of luck (and a lot of perseverance, I've been on the edge of quitting because I really didn't get the hang of it at first).
|
|
|
|
|
Sander Rossel wrote: and a lot of perseverance
Or plain stubborness.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
This thread is why I love CP. Just a treasure tomb of practical feedback with a bit of hot sauce tossed in from JSOP occasionally.
In reading, I agree with the others that your background will easily give you the practical knowledge to solve problems. You don't get an MS in Architecture without learning how to think creatively. Some of the best developers I've worked with have alternative degrees - music, math, physics. But, I think you need to be realistic and focus a bit. The boot camps might get you started, but in reality you're looking at 1-2 years of effort, probably more to the longer time period.
I underlined developer above (not programmer) to point out that we (developers) create applications to solve problems. As part of your learning process, you need to be looking for that moment when you say to yourself, "Dang, I get paid for this." And you're having fun. Obviously, you don't like architecture  There will also be times of intense frustration (as other's have mentioned above).
I happen to have an electrical engineering degree, and I love being close to hardware. In my senior year a long, long time ago, my project was to write a device driver for a daisy wheel printer using a parallel interface, and I was hooked. I've worked with missiles, test equipment, EW systems, GUI development for embedded systems, etc. Unless I am starving, I will never do anything web, and java script horrifies me.
So, if you pursue this interest, you'll find yourself learning a lot of different things (I STRONGLY recommend a class in data structures and algorithms once you get a few programming classes under your belt). Over time, you'll do projects that resonate with what you like. The other side of it is you'll get a really crappy assignment where you are paid a lot of money to overlook the crap.
Good luck. Oh, one other thought. As an alternative to "boot camps", go out to youtube and search for college classes that the universities are making available for free. I am routinely amazed at the amount of information available.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
m4444 wrote: if I can realistically self-teach myself programming in a few months,
Yes, I don't see why not if you have the aptitude. But note that "programming" is a bit like "knowing how to use a steering wheel". Just as knowing how to use a steering wheel isn't going to get you ready to race in the Indy 500, "knowing programming" is very unlikely to make you job-ready. It doesn't work that way. That being said, I encourage you to learn software engineering if you have the aptitude. It could lead to a very rewarding career and more happiness that you could probably imagine. No, really.
I urge you to read this Quora post:
Ravi Bhavnani's answer to "I want to start learning how to code. Where should I start? What do I need?[^]
/ravi
|
|
|
|
|
I can't use JSON for rendering a parse tree because JSON does not preserve the order of subelements and because of the way multiple values are presented it gives json problems.
XML can do it, because XML preserves element order and an element can be present more than once within its parent container.
But I don't want to bother if everyone hates XML.
What would you do?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
If XML is what you need use XML!
See your options and pick the best (optionally the 2 or 3 of them) and use it...
Neither JSON nor XML is rocket science... If using XML, just remember to provide a working schema...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
There can be no schema for these ones. Or rather, the schema is in EBNF, not XmlSchema/XSD
It's by design. This is a parse tree. The elements are going to be different depending on the input grammar.
For any input grammar, you should define one XSD to go with it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Maybe (however as EBNF is finite, and it makes the input finite, which makes outpute finite), but you can create XML schema for every grammar the same way/time you parse it... It should not be that hard...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
i can, but i have no real reason to although (related) eventually I may make something that compiles XSD documents into fast parser/validators for specific XML documents
what i mean is i can potentially do xml validation and xml parsing in one sweep. The XSD could actually speed up the parse compared to parsing raw XML
maybe down the road.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
looks like someone already had my idea. 
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
When would you ever want a parse tree as a string? Actually when would you want a parse tree at all, instead of building some more convenient (and garbage-free) representation immediately?
|
|
|
|
|
The way my parser works you can practically shape the parse tree however you want.
Plus you can hard type the values from the lexer - even with your own types.
So you basically get an AST straight from the parser.
Spitting to JSON just gives you a tree structure you can pass around as JSON
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I think I misread you at first so let me try this again.
I don't want to parse any strings. I created a tool that allows others to generate parsers to parse strings.
As to why you would want to - most of the internet runs on text based protocols. XML and JSON are text based, as are most internet data exchange formats.
Also there are things like programming languages. Say you want to parse one, or create your own. This helps with that, or making a query engine, making a SQL DB of your own, or parse SQL scripts whatever.
There are plenty of reasons to use a parser.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I know what a parser is, obviously. But if the output of the parser is a string (such as XML or JSON), then you're building some Rube Goldberg machine that keeps parsing and serializing and parsing again.
|
|
|
|
|
That's not the main output. It's just an option to use with the parse tree.
The output is actually a pull parser underneath it all, such that
while(parser.Read) {
switch(parser.NodeType)
{
case LLNodeType.NonTerminal:
case LLNodeType.Terminal:
}
}
It builds a parse tree using that, if you want it to, or you can use it directly
It works almost exactly like XmlReader
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
To me the advantage of using XML with Visual Studio is that all functionality is built-in, when using an external library like the Newtonsoft.Json.dll you can get in DLL hell.
Especially when using NuGet packages everybody seems to be using their own version of Newtonsoft.Json.dll 
Here is an Ebook about XML: https://bookdl.com/978-1484231043/[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
