I personally feel that software architecture isn't so much overrated as too much focused on abstract patterns instead of how to best solve common problems.
e.g. last year I needed to model an invoicing system, although this has been implemented hundredths thousands of times, there is very little generalized information on how to best do that so that it doesn't fall apart next year.
The areas that currently are better at this are mostly related to security and operations.
Yes, before we were using clubhouse someone was doing high-level planning in an Excel/Google docs. A few months later and even marketing is starting to use clubhouse and the milestone planning.
I think it really helps to not have 30 different unrelated stories to work on but plan them at an epic level so at least the things you are working on are related.
Even for things that are not really an epic I now tend to group related features together in an epic to make it easier to keep track and plan. (e.g. grouping 10 minor UX improvements together in one Q3 UX fixes epic)
I really like Clubhouse, but I'm somewhat skeptical about the free version. (even though it says 'free forever')
In the past two years multiple companies that initially had an affordable plan ( 10 dollars a month or less) for small companies had the same strategy: change the affordable plan to a free plan. And then within a year kill 90% of the features on the free plan and have you upgrade to a full plan much more expensive than the plan you were on before everything became free.
The product is great though, main feature for me is the ability to plan epics at a milestone level.
Educated or not you can't 'unhear' something. What if the conversation is political or financial and has major implications on someone you know? Will you still be able to remain professional and not act on the information?
I feel like devices like this should at least give the user the opportunity to play back whatever is sent for manual evaluation. e.g. it could send you an email at the end of the month listing the recordings it would like to use.
For example:
- bots sign up with email addresses that are owned by other people that don't appreciate your welcome/activation/etc. mails.
- all that automatically generated data can start to hurt performance. Especially on a smaller site, having millions of useless users in your database can slow things down significantly.
I think the most important issue why projects take longer is not because the time it takes to complete a task is uncertain, but because at the start it will always be unknown which tasks will prove critical.
The further you get, the more tasks will reveal itself that were not part of the original scope, but critical nonetheless.
You are not alone. Mostly an issue when using laptop in lazy mode on couch or bed. In that regard I miss the old laptop designs with rounded edges on both front and sides like my old Dell D400.
It depends a bit on the phrasing, but in all cases where someone asked if we would pay for vulnerability reports and we replied we would not pay, only offer acknowledgement on our security page, they would still share the report.
If you are going to pay, make sure you clearly state scope and the type of exploits you pay for. Otherwise there is a high probability of it being something in the realm of being able to iframe your site.
I don't really mind the new design itself, but the new font looks too blurry to look at on my non-retina mac. ( I suspect the -moz-osx-font-smoothing:grayscale) and it is insanely slow.
Luckily I can still revert back on GSuite for now.
I wonder if he actually tried it. I always thought the same about PR's for internal process, until I actually tried it. It made working with feature branches much more convenient.
I mainly use it to test if features meet their functional description before merging, but also reviewing the code at the same time does help to spot subtle misunderstandings in the requirements.
I also disagree that it would hold back development of inexperienced members of the team. Having the structure with PRs allows them to work on things that they otherwise may not have been trusted with yet to work on at all.
I'm basically the same, maybe a little less on the actual technical direction. What I feel is the biggest disadvantage is that you are the bottleneck for anything to move forward. I'm not sure yet on how to solve that.
A few changes you could try:
- have the developers make their own estimates
- instead of explaining all relevant existing code, only point to where the relevant parts are or what terms to search for)
- if there is a designer involved in the features, try to get them better at making specifications, so developers can work directly with the designer instead of having you in between doing 'translation'
Although I agree more with the original title, as that would be the exact message I need at this time, I would suggest to then at least also include Sierra, and El Capitan in the title as the fact that the document was updated is most relevant for users of those systems. Maybe reflect that something changed as well. Maybe:
About the security content of macOS High Sierra, Sierra and El Capitan [updated]
I mean smaller as in closer to zero as in exponent lower than 127. That part is obvious in the formula, but not from the graphs.
The interesting part of the explanation is that it shows very clearly the effect of the 1.M in the formula. Unfortunately it then does not answer the resulting question: how is zero represented. ( https://en.wikipedia.org/wiki/Signed_zero does a pretty good job at that though)
I'm guessing because if you put those words together, you automatically assume the offset means the position of the window. It's clear enough with the illustration, but using terms that are in very common use for other concepts can make it confusing at the first glance.
Also the window explanation hides the fact that it's able to represent really small numbers. (graph implies that 0-1 is the smallest window)
I feel one of the reasons so much software appears broken is exactly by leaving these decisions in the hands of programmers. This mostly happens because nobody else wants to make the decision either.
However, what constitutes a small bug vs a large one is very different for a programmer than for business.
'Just a spelling error in the signup form' may decide if someone becomes a customer.
While some rare edge case can take up weeks of reworking a solution, may have been covered just by a business decision not to support that case.
I'm still looking for a better way to deal with this as most QA testers aren't capable either to decide whether something is just a detail that everyone will gloss over or an important detail that makes all the difference for a customer.
Both often end up in the same large bin of 'some day' issues where developers cherry-pick what they feel like. (until a customer complains of course)
e.g. last year I needed to model an invoicing system, although this has been implemented hundredths thousands of times, there is very little generalized information on how to best do that so that it doesn't fall apart next year.
The areas that currently are better at this are mostly related to security and operations.