Time from enqueue to start isn't a good metric - it completely disregards the queue size. Enqueuing 1M jobs won't change this metric as it only updates once the job reaches the front of the queue, and when the 1Mth job does that the situation is already over.
I had much better results with a metric that shows estimated queue time for jobs that are getting enqueued right now (queue_size * running_avg_job_processing_time / parallelism).
I think that the area where I'd love some tool to help me would be keeping track of phone calls - ideally even attaching recordings to a proper company, transcribing them and summarizing. It's easy to get back to an email because stored but in case of a phone call I need to make notes quickly.
When I keep track of things in a text file or spreadsheet it's easy to get an overview quickly - because it's all on a "single page". I can even grep for some key word. I don't think Rolepad UI helps here. The current the company list shows only name, position and stage. I would like to at least see some "comment" for each.
The last time I searched for a job I created labels in gmail for each position and created rules to automatically label incoming emails. It was very easy, just select an email -> "filter messages like these" -> label (set new to jobs/company-name) and done.
While I could potentially use Rolepad to store notes about companies I doubt that I would forward emails there because I don't see potential benefits since Rolepad won't automatically update any entries on its own. Maybe if I it aggregated all communication channels? emails, phone calls, linkedin messages, etc
By the way - I use multiple email addresses (wildcard in my own domain) when contacting recruiters but the accounts have just one so the email forwarding won't work.
Definitely will acknowledge that searching the provided data has room for improvement. Re: emails, it actually does have some rudimentary capability to detect which opportunity the email should be assigned to, based on a few factors - this too will be improved in the future. One workflow I've thought about was adding save@rolepad.com to cc/bcc on your outgoing emails to avoid the extra step. I have also kicked around the idea of creating custom Rolepad email addresses to use on outgoing resumes so that all communication is automatically captured in the system. Felt a bit fanciful at the time, curious if there's interest.
The multiple addresses is a doozy, will need to noodle on this. I guess easiest would be manually associating multiple emails with your account. Or the whole custom address thing...
I don't think her conclusion is correct in this case (that it's all about chronological order). It's not about what happens first but about levels of abstraction. It doesn't make sense to say that we want to decide on the number of doors before specifying if we're building a LEGO car or a skyscraper in Manhattan.
The reasonable approach is to start from high-level concepts and only then deal with the details - without specifying high-level concepts the details have no particular meaning.
As a side note I have to say that I definitely prefer languages with `object.function` rather than `function(object)`, precisely because of this.
Another example: `if(foo == 5)`, not `if(5 == foo)`
This is completely another level of "issues" than other problems in this thread. During code review I'd only mention it as a nit. The longer form is correct and the only downside is that's a bit longer. It doesn't mess up code modularity or affect maintainability in a noticeable way.
Well, assuming that the language doesn't have any quirks in this area - e.g. in Java your statements aren't equivalent for a Boolean x.
Nitpick (as in general you are right regarding java as well): I’m fairly sure they are the same for java in this instance. Both will convert Boolean to boolean, throwing an NPE if it was a null.
Jira has a search bar which seems ok-ish. Except that I have to wait 10s after I open Jira for the search bar to start working because it's probably the last thing to become interactive after a page load :|
I haven't used them for real but (briefly) evaluated with the intention to maybe replace Jira, about a year ago.
Space wasn't there yet. IIRC the main issue was lack of a way to set custom fields via API, or some weird restriction around that. My general impression was that it was promising but too immature at that time.
For any Jira competitors reading this - start with providing 2-way sync between your product and Jira instance. It would make moving away from Jira soooo much easier!
The current state is that even importing Jira data is below what I'd expect - e.g. Linear (last time I checked) didn't import comments at all and all issue IDs were changed to new ones. Really, if there's FOO-123 in Jira it's table stakes for it to be also called FOO-123 in the new tool.
I wrote a tool to migrate an issue tracker to Jira which imported everything as expected and updated links in issue descriptions/comments to keep their integrity. It took few days for a one-time migration so I'd expect someone who builds a business in this area to just have that as a baseline. It's sad how bad the "import from Jira" journeys are.
> Using micro-services instead of monoliths is a great way for software engineers to reduce the complexities of their code
Could you share why you think that's true?
IMO that it's exactly the opposite - microservices have potential to simplify operations and processes (smaller artifacts, independent development/deployments, isolation, architectural boundaries easier to enforce) but when it comes to code and their internal architecture - they are always more complex.
If you take microservices and merge them into a monolith - it will still work, you don't need to add code or increase complexity. You actually can remove code - anything related to network calls, data replication between components if they share a DB, etc.
I don't like the fact that I need to grant read/write access to all public and private repositories to use the dashboard or create PRs. I know that github has no decent solution to limit access scope to 1 repository but this is the reason why I haven't tested graphite on any real work.
I guess that the only sane way would be to create a separate github user which only has access to a single repo where I'd like to use/test graphite.
At the same time I'd probably be ok with the CLI having wider access, as long as the website does not have it. I can control/monitor CLI to some degree but not the web part.
I had much better results with a metric that shows estimated queue time for jobs that are getting enqueued right now (queue_size * running_avg_job_processing_time / parallelism).