|
Exactly this, even if to be honest normal Coke is probably only a tad less chemicals than Diet and Zero. Diest is evil, I had an ex-coworker who almost died because of the faked sugar (Is it called aspartam also in Engelish ?). My lessons learned is : if you want to eat unhealthy things, then go for original, because everything else is worse.
|
|
|
|
|
Zero because I prefer the taste. I loved the first version of Coke Zero, it tasted like petroleum and I loved it. Second version was the bset, the new one is a bit too sweetened for my tastes.
I can no longer dring normal coke though, it leaves my mouth all pasty for all the sugars.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Diet Coke. Don't need the sugar in full test Coke. That and I don't like the taste of it. Zero tastes too much like full test.
|
|
|
|
|
I just drink a quarter of a litre of water and eat six tablespoons of sugar.
It reduces the weight of the weekly shopping by 37%, while having no effect on my sugar and water intake.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Hey everybody, I’m new here and in the market for a new career.
I'm seeking some advice on if I can realistically self-teach myself programming in a few months, or even do a 3 month “boot camp” and be job-ready?
I come from a more traditional place of having to get 3-5 year degrees… so I’d like to confirm if the above is actually possible or realistic? I’m 27, pretty good with computers generally, and hungry for a good job. However, i'm not a genius or anything.
The TLDR part of my story… trying to summarise as best I can:
-My 6 year relationship with my ex ended 4 months ago, pretty much shattered my world.
-I have a masters degree in architecture from 2015, I did 6 months post-graduate work which I didn’t enjoy and ended up leaving to run a business with my (now ex) partner. Now that’s just ended, I’m needing to find a job.
-I’ve got enough savings to last me a year without work, but I really want to get something ASAP.
-I’m applying to get back into architecture places, but not super keen on it. The job market is also pretty bad, not many opportunities and not great pay.
-I’ve been interested in programming before but never made a leap to study it or anything – nows the time though if its going to happen.
-I looked on seek and saw heaps of jobs with good pay and good future predicted growth, which is why I’m taking another look at it now.
So… is it possible to self-teach, or do a 3 month boot camp and be job-ready? How easy is it to get a job? I’m living in Melbourne (Australia).
Any advice / tips / ideas are appreciated!
Thanks guys
modified 12-May-19 11:48am.
|
|
|
|
|
Warning; first part sounds harsh, but read on. There's never a TL,DR in the documentation 
m4444 wrote:
I'm seeking some advice on if I can realistically self-teach myself programming in a few months, or even do a 3 month “boot camp” and be job-ready?
How about brain-surgery in 21 days?
Yes, you can learn some basics, but not enough for me to consider hiring you. The kids coming from the schools here have at least spent three years learning to code, have done 2 projects in a working-environment, and are fairly cheap. Why would I take someone older with an introductory course?
m4444 wrote: I’m 27, pretty good with computers generally, and hungry for a good job.
..you should also be willing to say goodbye to a part of your social life, and accept that while you program, you will be learning. You can't stop after x months and proclaim you're there - you'd have to learn continuously, also besides having a job.
m4444 wrote: -I have a masters degree
We're used to that. Most companies will ask you to write a short piece of code to prove you can actually write code.
m4444 wrote: -I’ve got enough savings to last me a year without work, but I really want to get something ASAP.
Get the book "head first c#", try understanding it within a month. Once you have gotten that into your head, you should jump into the semi-deep water and do a small project. Also, you should be daily on this site, after that month, trying to answer the easier questions you can scout. Most of them can be solved by reading the documentation, and it will expand your knowledge faster.
Before you begin, accept that it will not be a fun time, and the reward for the labor will come a lot later.
m4444 wrote: -I looked on seek and saw heaps of jobs with good pay and good future predicted growth, which is why I’m taking another look at it now.
Hahaha, "good predicted growth" is an empty sales-promise. I predict someone selling you a bridge 
Employers will make room, if you are willing, hungry and capable - regardless of the industry you're in. Don't expect to be making a fortune either. If you want money, you should become a banker.
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.
|
|
|
|
|
Hi Eddy thanks for the reply.
Do you think something like this is bullshit then?
How to become a developer and get your first job as quickly as possible[^]
Essentially he says to become a "junior web developer" first, and to learn "learn.freecodecamp.org" (HTML, CSS, JavaScript), then learn Git, then vscode/ codepen ... then build a portfolio, add it to your CV, and start applying (and keep learning while applying for jobs).
I guess a difference is that he has an engineering degree, which seems to be kind of related to IT? Where as my degree in architecture is more about design...
|
|
|
|
|
m4444 wrote: Do you think something like this is bullshit then?
How to become a developer and get your first job as quickly as possible
It is not entirely bullshit, but it is NOT as good as they try to sell you, and some of those camps, are not worth the costs they demand
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
modified 12-May-19 7:39am.
|
|
|
|
|
m4444 wrote: Do you think something like this is bullshit then?
How to become a developer and get your first job as quickly as possible[^]
Yes. SEO doesn't belong in a devs portfolio, and building a basic website is a skill lots of people have, even those who aren't fulltime devs.
To a dev, debugging-knowledge is not a bonus, it is a requirement. If you can't debug, you're basically working blindfolded.
m4444 wrote: Essentially he says to become a "junior web developer" first
That's a very large title for someone who is limited to HTML, CSS and bootstrap.
m4444 wrote: and to learn "learn.freecodecamp.org" (HTML, CSS, JavaScript), then learn Git, then vscode/ codepen ... then build a portfolio, add it to your CV, and start applying (and keep learning while applying for jobs).
HTML and CSS aren't programming languages. So, basically they tell you to make a very basic website, with only the JavaScript part being actual programming.
Lots of people who have learned JavaScript as a hobby. They created lots of free JavaScript libraries, of varying qualities. Some of them will have made the move to professional programming.
m4444 wrote: I guess a difference is that he has an engineering degree, which seems to be kind of related to IT?
I know too many people with an IT-degree who can't tell the difference between JavaScript and C#. The article represent the "what you need" section too much as a job-offering, where you need to be interested in the latest frameworks, SEO and having wordpress as a desired skill. To me, it doesn't read like a roadmap to becoming a dev, but more something a recruiter would list as a profile. Meaning 50% fluff 
Again, lots of people made the move to a paid programming job, coming from VB6 or webdesign. If they can, so can you - just don't expect it to be an easy ride.
m4444 wrote: Where as my degree in architecture is more about design...
I don't have one. Not really required in IT.
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.
|
|
|
|
|
The harsh light of reality:
0) I'm going to go out on a limb here and say no, you most likely won't be "job-ready" in three months, and even at 6 months, it would be a stretch. BVeing a software developer requires a certain mind set and aptitude.
1) If you thought the pay was bad in the architectural business, wait till you try to find a job as a programmer with no formal programming (or even IT) related education.
2) I've been programming for 40 years, and still wonder if I'm "job-ready"...
3) I can't imagine how difficult it is to start out as a new programmer nowadays. You're going to have a rough time of it at first - the pay will suck, the hours will be long, and the job is generally thankless, with clueless managers basking in the glory of your efforts. You'll likely spend YEARS on a given project, only for it to be abandoned or marginalized, but you should look on the coding you did as a learning experience and move on.
Advice:
0) Get an account on Pluralsight. They have training for pretty much anything IT related you can imagine.
1) Develop strong google foo. If you can't google for the info you need, you'll be stuck buying books that will only be viable for a year or so (yes, the industry changes that fast).
2) I think it would be easier/faster to become a SQL developer than an actual application developer, because SQL will always be SQL and changes at a much less frenetic pace than does application development.
3) Even if you don't become a SQL developer, you still need to learn SQL for most jobs nowadays, on top of being an application developer.
4) You HAVE to be willing to write code as a hobby. Many times, you have to learn new tech for something you're going to be doing at work, and managers don't generally want you to "learn" on the job. They expect you to miraculously just know how to do shit that is only a few days old.
Other stuff:
0) The one bright light is that most of the tools you need will be free, so, silver linings.
1) Get decent modern hardware. At least a quad core CPU, a bare minimum of 16GB of RAM (32 would be better), and a SSD hard drive (they're really cheap compared to even a year ago). Beyond that, at least two monitors would be really useful as well.
2) When you think you're ready to get a job as a developer, read this article - Being a Programmer[^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: you'll be stuck buying books that will only be viable for a year or so (yes, the industry changes that fast).
It's not like a book on .NET 2.0 is suddenly non-viable. How old is the head first c# thingy now?
#realJSOP wrote: 2) I think it would be easier/faster to become a SQL developer than an actual application developer, because SQL will always be SQL and changes at a much less frenetic pace than does application development.
I like my SQL92, yes, but querying a database is not development, and is not often asked as a standalone skill. If someone is designing a database, you'll need to know a few things more than just SQL.
But yes, your post is spot on 
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: How old is the head first c# thingy now?
I don't even know what that is.
Eddy Vluggen wrote: querying a database is not development, and is not often asked as a standalone skill. If someone is designing a database, you'll need to know a few things more than just SQL.
I know some sql devs who will rabidly disagree with you. SQL dev work is (I think) significantly different from app dev (using the various languages available). You gotta think a whole different way. You also have to thoroughly understand the db environment.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: I know some sql devs who will rabidly disagree with you.
Why?
#realJSOP wrote: SQL dev work is (I think) significantly different from app dev (using the various languages available).
It is. Querying is not programming.
#realJSOP wrote: You gotta think a whole different way. You also have to thoroughly understand the db environment.
Some database-theory, like normalization.
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: It is. Querying is not programming.
We have stored procs that are as long as 1400 lines (which I personally find disturbing). Believe me - it's programming, and you're significantly over-simplifying it.
Out of the hundreds of stored procs we have scattered over more than a dozen databases, we probably have five or size that are simple select queries.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: We have stored procs that are as long as 1400 lines (which I personally find disturbing)
I've seen someone be "bright" and store 31 booleans as 0 and 1 in a string. Having it doesn't mean it is a good idea.
#realJSOP wrote: it's programming, and you're significantly over-simplifying it.
Writing a sproc is manipulating data, yes, but it is not programming, nor is that the most important aspect of a DBA-position.
#realJSOP wrote: Out of the hundreds of stored procs we have scattered over more than a dozen databases, we probably have five or size that are simple select queries.
Sounds like a maintenance-dream for anyone who is afraid to run out of work 
I don't care about sprocs, they are a layer on the db-structure itself; and unless that structure is in 3.5 NF, I'm not touching it. How would your boss react to that? 
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 think you 2 are discussing the difference between a programmer and a developer. The latter will be expected to have database skills.
The OP does not know the difference.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Mycroft Holmes wrote: I think you 2 are discussing the difference between a programmer and a developer.
Nah, IMO writing an sproc is "scripting", which is a user-acticity, like scripting in VBS. If you want to program, you need a programming language, not a scripting-language.
And for most people in this world, a programmer and a developer are the same thing
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: writing an sproc is "scripting", which is a user-acticity
You're seriously kidding, right?? The time I've spent over the past quarter-century rewriting badly-written SPs (written by junior devs, not even users) is substantial, and the effects of their efforts at destroying database - and therefore application - performance and thus usability is even more so.
I'd argue that a SQL Dev is not someone who knows how to write a SP, but someone who is capable of taking business requirements and designing a suitable structure (which involves a lot more than just normalization) AND access model, and then (maybe) is also able to develop SPs. Those SPs also require debugging skills. The conversion of business requirements to database model is not done in isolation, but requires a deep understanding of the way the (proposed) application(s) will function and very close liaison with the other developers.
Also, there are elements to SQL that maybe you've never come across if all you've needed to do is "run a query".
|
|
|
|
|
DerekTP123 wrote: You're seriously kidding, right??
No, it would have a joke-icon if I was, and I don't find this funny at all.
DerekTP123 wrote: The time I've spent over the past quarter-century rewriting badly-written SPs (written by junior devs, not even users) is substantial, and the effects of their efforts at destroying database - and therefore application - performance and thus usability is even more so.
So? Most of it is not done by a trained DBA.
Also, "user" is not limited to untrained personel that only uses the GUI someone built. YOU are an end-user for some products, even as a developer.
DerekTP123 wrote: I'd argue that a SQL Dev
There is no argument.
DerekTP123 wrote: is not someone who knows how to write a SP, but someone who is capable of taking business requirements and designing a suitable structure (which involves a lot more than just normalization)
I never claimed that normalization is all they need to know, that's just a shortcut for me to evaluate what I am dealing with. A DBA will happily chat about the difference between the logical data-structure and the difference with the structure on disk, and can actually explain the performance-statistics that SQLSMS generates when executing a query. Being proficient with SQL is not enough, but that also goes for any developer worth its salt.
DerekTP123 wrote: but requires a deep understanding of the way the (proposed) application(s) will function
The app does not determine how the database is structured; the app is merely a layer, and will have to use the structure as determined by the DBA, which will base it on requirements. That's requirements for which data to hold, not for what the app should be able to do.
So, no, nowhere do I imply that a DBA is the same as your end-users. Some years ago, EVERY user needed training for their tasks. Nowadays, people with training are considered too expensive.
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.
|
|
|
|
|
Some interesting responses there, and I think we agree on much. However I'd still contest that letting end-users - even with reasonable SQL skills - loose on writing Stored Procs is a bad idea. For one thing, in very many scenarios, the end-user does not (or should not) have permissions to see the full structure of the tables they're dealing with, and certainly not a deeper understanding of the database structures - nor of other applications that also need to access the data.
For low volume (size and transaction rate) databases it might not hurt too much, but a single badly-written (by which I don't mean poor syntax, I mean inappropriate for the situation) SP can wreak havoc on a high-volume or high-activity d/b.
Eddy Vluggen wrote: Being proficient with SQL is not enough
which I think is the point I was trying to make; probably failed to express it well.
Eddy Vluggen wrote: The app does not determine how the database is structured; the app is merely a layer, and will have to use the structure as determined by the DBA
Generally, I'd agree with you there; however I think it's often a chicken-and-egg situation, and 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, but also project over-runs and severe internal ructions. Too much delineation between roles, lack of communication, inflexibility and "empire-building" is never good. Development involves ongoing negotiation and collaboration and a new app with a unique access pattern may require more than just whacking in an extra index or two!
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
