81–90 of 103 posts
This is great, although I have a different approach, namely https://www.somewhere.com and specifically https://www.somewhere.com/what-is-somewhere
Earlier quoted context omitted.
When you start dividing responsibilities horizontally like this, IME you end up producing worse software. Being responsible for testing drives you to good design. Being responsible for deployment raises considerations you might otherwise miss. When development and QA are separate it's all too common for only one to have an understanding of the actual customer requirements. Better to slice vertically. Everyone takes r…
If you have ever read about Carrot in Pratchett's Discworld series, you may have a new understanding of laziness. Carrot, you see, is so lazy that he exercises every day, because it is easier to accomplish things in a fit body than in one that is fat and weak. Testing your own code is that sort of laziness. You write automated unit tests so that you will never have to look at or touch that particular bit of code ever…
Sure, testing can be extremely useful and important in some cases. I'm thinking of complex engines that power business flows and applications. Testing user interfaces and MVC controllers is hypercorrection and usually a waste of time.
Great 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…
Appreciate the feedback.
Great 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…
This is a fair point and something we are actively pursuing. Right now the radar plot represents a trade off between an effective interactive form of visual input that is also compelling and provides an easy mechanism for visual comparison (with the shapes overlapped). Appreciate the feedback.
Earlier quoted context omitted.
I like the concept but personally when I look at a resume I never* look at job titles anyways - they're effectively meaningless when compared between companies. Instead I read what they self-describe themselves to be doing, which is basically what you're doing albeit in visual form. * Within a single company titles usually are meaningful, so title changes while staying at the same company I'll take note of - particul…
Once you get to a certain size of company, you have the normal career path of (entry level functional job) > manager > director > vice president. Depending on the size of the company, there may be sub-levels such as junior/assistant > senior > executive/general. The levels usually mean the same thing across companies. If someone goes from a manager to a director at a big company, that usually means something. Dependi…
It bothers me that that's considered a "normal" career path. The skills that make someone a good engineer/architect/etc do not necessarily make them a good manager or VP; even if they do end up doing well in a management role, they're then not actually using most of their technical skills. To me, it's a sign of a dysfunctional company if there's no technical advancement path.
Job titles tend to vary more in technical roles, but at least within the computing field, there's a normal career path that goes roughly engineer -> architect/lead/etc -> principal/distinguished engineer -> fellow. There are often several levels within each of those ("senior", etc), and smaller companies may omit the pre-fellow stage (the name of which tends to vary). For many companies, a quick search will turn up what set of titles they use for the top few tiers.
I would hope that isn't unique to software engineering, and that other fields have the concept of advancing within that field without becoming a manager.
Earlier 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.
Earlier quoted context omitted.
This is a fair point and something we are actively pursuing. Right now the radar plot represents a trade off between an effective interactive form of visual input that is also compelling and provides an easy mechanism for visual comparison (with the shapes overlapped). Appreciate the feedback.
Yeah, if you can come up with a way to give the viewer a "sense" of the person at a glance it would go a long way. Maybe add colors? Or maybe consider that some metrics are pretty related and could be represented separately. Frontend / backend could be represented as a continuum by itself. UI/UX are sort of tied with front-end, so coming up with a way to link those together might be nice. Perhaps you could use the da…
As for the trends check out these links to see histograms showing related aspects according to different job titles:
https://www.workshape.io/infographic/frontendengineer https://www.workshape.io/infographic/backendengineer https://www.workshape.io/infographic/fullstackengineer
Earlier quoted context omitted.
ukigumo, your experience is the reason why Gordon and I started Workshape.io - all the information out there is historical - what you have done in the past - and nothing at all on what you want to do in the immediate future. Glad you like the service - keep an eye on us, there's a lot more to come
Good to hear you guys have a vision. May I offer some advice though? Big corp also needs help finding talent (maybe more so than startups) so you may want to _also_ target that market segment going forward. Good luck!
Yes, job titles an CVs/resumes are out of date. People talk about the future of work but for a lot of us it's already here. This is great, although I have a different approach, namely https://www.somewhere.com and specifically https://www.somewhere.com/what-is-somewhere
Generally what I look for on a CV or whatever a potential applicant sends over:
- Where have they worked? For how long? And what did they do?
- What did they study?
That's it - I have about 5-15 seconds to find and read that information. If there's something there that I like, then I dive into the rest of what they've written. Am I still interested? Now I'll start digging through their portfolio, web presence etc.
What I am not interested in (until much later in the hiring process) is the random blurbs / thoughts that make them who they are which I think somewhere.com puts on the forefront. It is something I'd glance at to get a feel for who they are as a person, but it really doesn't solve the "CV" delima (if there is one).