Finally, a Rorschach test for developers!
The Problem with Job Titles
71–80 of 103 posts
Re: The Problem with Job Titles
#72So, first things first: Love the software and the concept of visualizing your activity spread in a radar plot. Well done! Now for the rant: I am an IT architect. There are many architects working in IT but few of them do anything that is related to what I do. I see job postings for Enterprise Sharepoint Architect and I cry a little, others for CTO/Architect/senior developer and I question if they are maybe hiring for…
If you think "architect" is too vague, think of the poor "vice-president" :) As you say yourself, "I often have VPs working under my direction"
Good point, people and function managers get called all sorts of job titles, VP, Head of, Team Lead, Manager, etc and its funny to see how multinational (specifically EU/US) companies deal with this since there is a bit of a "dick measuring" competition for nicest sounding titles among peers.
Re: The Problem with Job Titles
#73Great underlying data, but sad to see it visualized as radar charts.
- Each category majorly affects the reading of the category next to it, which isn't helpful in non-sequential categorizations
- The difference between two adjacent categories creates a unique angle and shape that is purely extraneous information
- The relative sizes are hard to read as the underlying quantities aren't proportional to the displayed areas
Although not the prettiest possibility, a grouped column chart (maybe groups for front-end, back-end, maintenance, culture, etc.) is a simple example that avoids many of these issues and has very good readability at a glance.
Re: The Problem with Job Titles
#74Earlier quoted context omitted.
Exactly. I have a lot of acquaintances who self-describe as data scientists. They really run the range all the way from "they poke around with Excel" (ie not only could I do that in my sleep, but you couldn't pay me enough to do soemthing that dull) all the way to "novel algorithm design at the frontier of the field" (ie I could take classes, train, be mentored, etc and never be able to do what they do).
> Exactly. I have a lot of acquaintances who self-describe as data scientists. My understanding is that "data scientist" is a term meaning "statistics person who lives in San Francisco"
Or, another version, "programmer who read an inferential statistics tutorial online".
Re: The Problem with Job Titles
#75Earlier quoted context omitted.
Yeah, I agree on principle. But sometimes you look bad in front of QA because you ask them to do their job. To give you an example - I was implementing an achievement for a console game. The achievement took roughly 3-4 hours to test fully. I was specifically told by my manager to do my best to make sure that it works,but not to spend time testing it myself,because it would be a waste of my time - it's QAs job to tes…
Seems like you should have been able to give QA a game state that was close to the achievement. Even having QA burn 4 hours of time is wasteful when a game is nothing other than state that can be loaded to any arbitrary point.
Yeah,but the achievement consisted of 44 individual triggers, and for the test they had to trigger all 44. You couldn't give them a state with 43 already triggered. Not to mention that if you change the achievement triggers you have to wipe the save data in make the new triggers work, so they had to start from scratch every time. But fortunately it only had to be done twice in the entire project.
Re: The Problem with Job Titles
#76Earlier quoted context omitted.
One problem I have w/ the back-end/front-end distinction is that at least to me that implies one is working on a web or mobile application. For instance, the product I work on daily has no UI (ok, it has a 2 page UI used by an ops group) - is that "back end" when there's no "front end"?
Your front-end is your 2 page report. It's not about size but separation of concerns, nothing to do specifically with web apps.
Right, although to me "back end" implies "feeding the front end" which isn't the case here, rather that 2 page report is more of a side channel and the consumer is another data processing engine.
And apologies - this is a bit OT here and I'm not trying to be difficult nor argumentative, I've just often wondered if the majority of people view backend/frontend as specialized terms like I do or if it's really just a generic term for "works on visualization/UI" and "works on the other stuff"
Re: The Problem with Job Titles
#77Earlier quoted context omitted.
You're looking at this through a purely technical lens. The guy who "pokes around with Excel" probably operates in a business context. He interacts with people who have no clue about data science, and is able to use the data to tell a convincing story. This can be dangerous if he doesn't know what he's doing, but 90% of things people want to use "data science" for are pretty trivial technically and probably can be do…
Many things are simply complex and there is no way to 'dumb it down'. QM is probably the best example where the 'every man' description has almost nothing to do with the underlying theory. In the CS encryption is probably the best example of this where the basic algorithm can be identical between a system protected from the NSA and something trivial to break for the average researcher.
Yeah, but your code is ultimately achieving some business requirement or it wouldn't be there. Being able to articulate that is an invaluable skill. Requirements are generally poorly written, so if something needs to be done a certain way (e.g. so the numbers in the reports across multiple products are consistent) then the business sometimes needs to know the algorithm.
Re: The Problem with Job Titles
#78Great underlying data, but sad to see it visualized as radar charts. - Each category majorly affects the reading of the category next to it, which isn't helpful in non-sequential categorizations - The difference between two adjacent categories creates a unique angle and shape that is purely extraneous information - The relative sizes are hard to read as the underlying quantities aren't proportional to the displayed a…
Agreed; spider graphs really aren't helpful past about 5 variables.
Re: The Problem with Job Titles
#79Great underlying data, but sad to see it visualized as radar charts. - Each category majorly affects the reading of the category next to it, which isn't helpful in non-sequential categorizations - The difference between two adjacent categories creates a unique angle and shape that is purely extraneous information - The relative sizes are hard to read as the underlying quantities aren't proportional to the displayed a…
Good point, but I could imagine certain shapes becoming very recognisable after a while. Ensuring the ordering is such that a 5-1-5-1-5...pattern is unlikely, since these spiky shapes will all look the same. And yes the angles don't carry any extra information, but they are a helpful guide to the eye. I can see where you're coming from, but thinking about these plots a bit more carefully I think you are too dismissive.
Re: The Problem with Job Titles
#80Earlier quoted context omitted.
Thanks for your comments. Whilst we cannot remove ambiguity completely from our solution - we can minimise it. The ambiguity of text really comes into play in CVs and job descriptions. We attempt to minimise the ambiguity by asking software engineers/anyone involved in software development to describe their work in a uniform way and not relying up the traditional artefacts. So whilst the terms have ambiguity to them,…
I find it interesting that your graph leaves out any mention of innovation or invention. It also ignores corporate cultures. Backend engineering for a web startup is very different to backend engineering for a Wall St HFT house. I wouldn't expect someone who worked in one to be expert in the other. Even within the web startup world, fullstack with MEAN is very different to fullstack with PHP/Apache/MySQL - not just t…
(1) Surely culture and technology stack are reasonably independent of the dimensions considered here
(2) Wouldn't you agree that this asks an important question which is currently absent from the hiring conversation?
(3) Even if the spider plot is an imperfect representation, isn't it a helpful starting point for a conversation between a potential employer and employee?
(4) I'm not sure what your concern is about toy models and management. All models are toy models, the only thing which matters is whether they lead you to ask the right questions.