I guess it depends on what is meant by "automate"

I suspect what he means is "people usually do this stuff manually in excel" in which case what you want is a top notch data manipulation environment. R is pretty good at that. I think it's *arguably* easier to learn than python per unit of productivity you get out of it.

If it's more like "I need to scrape data from this web page and combine it with data in this database and then serve the data as a PDF" then yeah, python is going to be much better.

Long term python is probably a really good choice. "Panda" which I mentioned before is, more or less, a replacement for R in the python language. I'm not really saying that python is a worse choice, but more that there are going to be more hurdles between being a novice and being productive.

At least, I think... tbh I have not done much R but I used to be a Matlab expert, and I believe they have a lot of similarities. I got a ton of mileage out of matlab + shell scripting when I was an engineering student.

It's tough have a good attitude in regards to what you do when you have such a toxic attitude towards the tools you're using.

There are dead-end jobs in any language and great jobs in any language. One way you don't end up in a dead-end job is by recognizing that a fashionable language does not make up for a bad situation. Lots of mediocre employers use trendy technologies to make up for the fact they do not otherwise offer a compelling opportunity. The two most desirable large tech employers are Google and Facebook and they are known for primarily being a Java shop and a PHP shop respectively.

Also, it's going to be tough for people who are prejudiced the way you come across to actually recognize genuinely interesting opportunities. In the 90's the attitude you're showing was generally held by C/C++ programmers who viewed any "easier" language with disdain and Lisp programmers who held less expressive languages in contempt. To these types of C/C++ programmers, Java was another VB-like language that no *real* programmer would ever touch and to Lisp programmers, Java was an unusably dumbed down version of Lisp with a C syntax to appease the riffraff.

Do you think technologists tend to be biased in the direction of thinking that there are no differences between technologies? That's absurd. Technologists tend to err in the direction of dramatically overestimating differences between languages or for that matter between technologies in general. Also, to deal with the example at hand, PHP is not a bad language to work with for the advancement of one's career at any level. And this is context-dependent. What would be a great technology to learn for someone who's trying to move up from 150K-175K range to 250K-300K range may not be great for someone trying to move up from 50K-75K to 125K-150K range. There are regional variations as well. I don't feel that the three of you (ChrisV, Craggoo and goofy) are sufficiently well-aware of what's going on in the broader technology field to give appropriate advice here. And the further one is away from reaching one's potential, the less any of this really matters. Below a certain level, which Noodle is a long way from reaching, experience in terms of language virtually doesn't matter at all.

You're moving the goalposts as you were the one implying that PHP is objectively bad for one's career. For example:

So now you're trying to say that well, being a PHP expert may be a great thing career-wise, but you personally don't like PHP and would rather take less money to do something else? How is that useful for anyone?

Aside from thing being a completely useful statement of personal preference, it's also absurd because in any kind of real technology job, the programming language is by far the least unwieldy and inconsistent thing you'd be dealing with and the level of inconsistency in PHP is completely dwarfed by inconsistencies you have to deal with in the rest of the stack, let alone non-technical aspects of the job. Unless you're a mathematician, your entire job is about dealing with inconsistencies - internally consistent things don't demand a lot of human labor.

There are good economic reasons for this but virtual all code bases that make a lot of money are abominations.

To me it reads like being more productive gives you less professional satisfaction. Again, unless your job is mathematics, no one is paying you to deal with consistent things because it doesn't add value.

[Candybar] is on fire

Well said.

After 20 years of programming just about all I have to say is that every codebase I have ever seen is a giant dumpster fire. I am sure there are exceptions out there, but I haven't seen one yet.

In my own personal projects I will occaisonally start with something that is (imo) well thought out and structured. By the time it can do anything useful I usually hate it.

I have always tried not to be a language bigot. I have usually failed. I have sometimes changed my mind.

Hah and one constant: no matter who's code I'm working on this week, THIS one is always the worst.

P.S. This one I'm working on right now, it really is the worst!

Trying to do a regular expression for the following:
I'm wondering about the octals. I'm assuming 0135 is okay but 00135 is not okay. And also, 0 is not okay. This correct? They way they describe this, 0 should not be in the set of Numeric constants in C.

This page describes 0 as a valid decimal integer, even though that breaks the rules they lay out. In any case, 0 is definitely a valid octal integer.

Edit: Also, I think it's a (really) bad idea to write a regexp that matches any valid C numerical constant. Write one for each possible type and try to match all of them. Will be a lot quicker (to write) and is way more understandable and maintainable to anyone encountering the code.

Re candybar's post, things I agree with:

- That there's nothing fundamentally wrong with PHP and writing code in it can be a reasonable choice from a business point of view.
- That there isn't a perfect correlation between languages/technologies being employed and quality of job. I disagree that there isn't a significant correlation, however. The example of Facebook is a bit of an outlier.
- That developers generally overrate how big a deal it is what languages etc are used. And in particular, that pet choices of nerd developers (like Lisp) can be counterproductive from a business point of view. I've ranted about that ITT before.
- That my "avoid at all costs" was hyperbole and was overstating the case. I was giving an opinion.

That brings me to this:

This is kind of the crux of it. I wouldn't care if you'd said "Craggo and ChrisV are wrong here imo, working in PHP is not an imposition". OK, we disagree. But what you actually said was that our posts were stupid and objectively wrong. Not liking PHP is hardly some weird vendetta peculiar to me. Polls generally show it to be among the most hated languages ever. So turning the question back on you, how is it "useful" for you to declare that people should be fine to work in PHP when all the evidence is that a lot of people aren't fine with it? Yours is the minority position here.

.....
Stating a codebase is an abomination isn't very descriptive. I think more detail would make for an interesting discussion.

I'll start:

-- Directory structures that are nested deeply where it is difficult to tell at first glance what is actually contained there.

-- Product builds that require complex build scripts because source files are pulled from many places and the logic of how things fit together is not clear.

-- Inconistent code documentation where standards are haphazardly applied.

-- Defective code.

Language snobbery is dumb.

Some pet peeves of mine from recent jobs

- there are a bunch of modules. Each one has an api.py and a data.py. The api has a shim script that turns around and calls the data script. All the functions are named something like "delete", "get" etc

So first, everything becomes impossible to grep because literally everything is
import api from foo
...
api.get()

Second, although it's a nice idea to seperate the data layer so you can change your backend, the frontend shim's arguments are already tying it to the implementation (they contain mongo collection names, mongo query fragments, etc) so it's pointless

- inconsistent data identifiers - that same system had a thing called, say, "foo" in it, where foo is a type of record in a database. Identifiers for foo that existed:
123 - i.e. an integer
"c_123" - i.e. the same integer with the character c in front of it
"foo" - i.e. a short string
all of these uniquely identify the same entry in the database. Which one does a given function take? Apparently rand()

- all the code is in one or two files (and they're each many thousands of lines long)

- all the business logic is strewn throughout the system, and repeated. Like I'm working on something right now that validates API inputs. The validation is repeated (and not exactly the same!) for inserts, updates, "edit suggestions" and "accept edit suggestions" (the last 2 are endpoints where someone can suggest a change to your Foo and you can accept or deny it)

(AND fairly trivial validation takes up 10x as much code as it should because of copy paste validation of similar parameters)

- database abuse - my favorite recent one is that say that you have a table of Foo and each Foo can have multiple Bars. Normally in SQL you'd have a foo table, a bar table, and a foo_bar table that is just rows linking foo_id to bar_id. Not here!

Here we have an element of Foo called "bars" and when you want to add another bar, you
load the foo record
append to bars
save the foo record

- call stacks that are ridiculously deep/complicated because everything is shoved into some 3rd party framework that almost but not quite does what you want and almost does what it's documentation says

perhaps the being stuck-up and ego-invested part is, but that some languages are much better than others is very real.

nice list of examples!

This leads me to ask questions like "are their syntax checkers and how do they handle this" or "how does the C preprocessor handle this". I don't know your particular use case but using regexp intuitively doesn't seem like the right answer, though I may just be too ignorant about the subject.

yeah as suspected my truthful, concise, non-vitriolic review was deleted, so **** that place. fyi.

This is such a load of ****, did you even read my post? I didn't go into my first job thinking "wow unit tests blow, I'm not going to take this seriously", my whole point was that I didn't know **** at that age and I went into it not knowing that writing unit tests all day sucks and isn't fun. You're right that that's my opinion and that it's not an objectively bad career choice, but with the experience I have today, I would wager that lots of programmers who enjoy development would not enjoy writing unit tests all day as a career, as I learned I didn't.

I did take my job seriously, and try to learn as much as I could from it, I just ultimately learned that I didn't enjoy it, and wrote a post expressing that I wish ~10 years ago someone had given me some advice about how some programming jobs are more enjoyable than others.

I didn't think that could be so controversial, but candybar has a bone to pick so jfc, here we are. I didn't like my first job writing unit tests and Craggoo and ChrisV think that there are more fulfilling directions Noodle could take his career than working with PHP forever, and candybar wants to go on for paragraphs and paragraphs about "well actually that could be a great career choice and you could make lots of money doing it", which nobody ever denied of course.

That's total bull****. You should really post about it. https://www.reddit.com/r/cscareerque...elete_reviews/ Post the full review here and maybe glassdoor will reply.

eh too lazy and don't want to deal with the doxxing/outing thing. "Coincidentally" I got a rejection email yesterday (over a week late) so they clearly were notified of the post and probably flagged it and it was auto deleted or whatever. Maybe they'll get their act together, or not, what do I care. Good story to tell at meetups obv.

Someone somewhere who washed out of a career in programming and went into project management is thinking:

"I wish someone told me that writing code all day sucks and isn't fun."

If you're a software engineer and you're not writing unit tests all day, you're probably doing something wrong.

And this is the exact kind of nonsense I'm pointing out. No one could have possibly given you appropriate advice about your own preference. And no one needs that kind of advice - if you don't like something, you will know, it's not something you need to be told.

And like ChrisV, you're backtracking:

You're clearly insinuating that you have some kind of long-term perspective here about why career in QA or test automation or whatever is bad, above and beyond the fact that it's not enjoyable for you personally. Why does anyone need a long-term perspective to know that if you don't like something, you should probably try something else?

Again, why does anyone have to be told this? If I got a job doing something and didn't enjoy it, why would I have to be told that I should not try to make that my long-term career?

All of this seems to me like you guys were trying to make a point at first about the inferiority of unit-test writing jobs and PHP programming jobs and are now trying to hide behind personal preferences.

And I think there are more fulfilling directions most of you can take your careers than being stuck at a level where you think things other people have created that you're using define your careers. You need to start judging your career by the quality of things you create, not by the quality of things you use.

This is a bull**** relativist argument that has no place in this forum. Acting like all opinions are worthless and we should only peddle in objectivity might be useful for dragging out internet arguments but isn't actually useful or interesting.

Wrong. Advice about other people's preferences could have better informed me what I'd be more likely to prefer, assuming I could identify common traits between myself and the people giving me advice.

This is where you so often go wrong, man. All these wordbombs you write rely on incorrect assumptions to begin with. There's no backtracking here, you just launch off into your own little world about what you thought we were saying, and then build and build on it.

Ok, fair enough.


yep.

I don't agree at all. He didn't post anything deragatory, make a personal attack, whatever. He is just challenging your beliefs. How do you handle code reviews? Code reviews are about people critiquing something you take a lot of pride in doing so in my mind that is much harder to deal with than beliefs about how to manage a career.



My reaction to your negative remarks about writing unit tests as a primary assignment was that I disagreed with your assessment. I can see a lot of value for inexperienced developers in coding unit testS. Actually I can see a lot of value for any developer doing that at some point in their career.




You're making it personal. He didn't and you shouldn't.

You can't on the one hand refuse to defend your point (unit testing as a career sucks) and hide behind personal preferences and on the other hand talk complain about relativism. If you think your preferences are more meaningful than a project manager thinking software engineering as a career sucks, then make the case.

And opinions are not the same thing as preferences.

Yet you have a lot of problems with my preferences.

There's no incorrect assumption here - literally right after you hid behind "personal preferences" you went off about how I'm making a relativist argument. Make up your mind.

That seems like a similar statement to candybar's - you can see value in it, which I also never disagreed with, but would you enjoy it? Would you go home from writing unit tests and feel fulfilled with what you're doing? I never said there aren't valuable things you could learn from it, I said I didn't like my job.

I certainly apologize if it's unwarranted, but candybar so often winds up misconstruing what his opponents are saying and torturing their positions into something they aren't - and not just with me, as his current discussion with ChrisV shows - that I find it harder and harder to believe it's just an accident. And engaging in bull**** like that just to "win" arguments on the internet is supremely annoying, and is certainly coloring my reaction to his posts at the moment.

I've learned to not engage our own little Hen.ryVIII

You're more guilty of this than I am but if I'm doing this and this bothers you, you should be able to point it out. I'm pretty much pointing things out as I see them and you're so wound up in this "must attack candybar because he makes me feel bad" mode that you're seeing things that aren't there. It's not my fault that some of you have these weirdly antagonistic views towards certain technologies and certain careers and get super emotional when you're called out on it. You literally have trouble believing that someone might enjoy something you didn't:

I don't believe that anyone who would say something like this feels fulfilled with what they are doing. Fulfillment requires a certain level of respect for the human condition.

Btw, I fundamentally don't believe you guys. I don't think any of this has much to do with what you enjoy or don't. It seems to me that the lack of enjoyment came largely from the perceived lack of prestige, which would also explain the reaction here. People tend to be much more defensive and vocal about their preferences when they are derived from status-seeking than about their genuine preferences. It seems that you guys are still firm in your beliefs that there's something objectively inferior about a unit-testing career (can it be fulfilling? lol) or a PHP career (dem inconsistencies) but are somewhat ashamed to admit that.