Michielvv

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 learned about clubhouse.io last week. Testing it now, but it seems very nice. Just enough configuration and structure.

(We are coming from Trello which just doesn't deal well with a large number of tickets as you have only one view on them.)

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.

Can be more accidental. e.g. dumping full POST data in a more generic way (e.g. on exceptions) that happens to also be applied on the login page.

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)

In our case the reason we switched from SMTP to an HTTP API was mostly speed. At least for Sendgrid, their HTTP API is much faster than SMTP.

In general I agree that I'm not seeing a big advantage in having another service to keep up and maintain, just to wrap SMTP.

Seems if you click enough, the tax site does mention it in some obscure tool. I always thought it only applied to goods.

For the dutch: https://www.belastingdienst.nl/rekenhulpen/diensten_in_en_ui...

Exactly the same experience here. I always felt bad about those periods that I wasn't able to even put in 20 productive hours a week, until I started writing detailed hour log: every bad period was always preceded by a very productive period where everything seems to come together.

Even the last three weeks: I was stuck on a design problem and couldn't really move forward/get productive for two weeks. Then when the solution finally clicked you can have a few days of just coding it all, that feels so much more productive.

Also got similar experience with being able to easily work 16 hour days on tasks that always have a clear and small next step, like CSS/design fixes.

What I've learned is to take advantage of those days that everything just works out and make the extra hours and not feel guilty when they don't. Works much better for me than trying to stick to a fixed number of hours per day.

In the projects that I was involved in in the past years, the ones that decided to build a scalable infrastructure before gaining traction were exactly those that were burning cash on infrastructure. There is just a reasonable minimum of servers you need to run such an infrastructure and then you need something similar as a staging environment to make sure it all works together correctly.

That being said, there are of course choices that can be made early on that will help you in case you need to scale at some time. Spending a bit of time thinking through what would happen if you do need to split up and scale out your system will help you avoid pitfalls such as relying too much on the local filesystem being shared across pageviews.

In general I believe there is more benefit on spending time on performance early on. (not caching, that is just postponing the problem) as it benefits not just your ability to run on a single system for much longer, it will also make life better for your users.

I agree the title is confusing. As far as I understand everything is unsupervised except for the sentiment neuron. The paper itself is actually a better read.

Yes, my experience is similar. A typical task will take at least 3 or 4 pomodoro.

There are few important aspects that contribute to being able to continue easily: - you know the Pomodoro ends at a specific time, so you can properly close, make notes, etc. - because you stop 'in the middle' you actually feel eager to get back to it. (contrary to normal breaks where you probably stopped because you didn't feel like working anymore)

In general I believe it works because you rely less on flow. Flow is great, but it also comes and goes. If you can easily get into your flow and stay there for hours, you probably don't need this, but for those weeks when it doesn't come naturally, this can really work.

At the same time, what is expected from those solutions in terms of features, usability, security and reliability also grows. So I'm not sure it will get worse, it will however change the skill set required. As it has been changing since programming exists.

Although I can see the reasoning, this absolutely does not work for me. The times procrastination bothers me is exactly in those cases: when there is something important but not exactly specified at the top of the list. I'll feel guilty about not working on it and then end up in a sort of limbo between the task I could be doing and the 'important' one.

What helps for me is exactly the opposite: deciding this important task does not have a clear path forward and therefore go write down each and every question I have about it and need answered before moving forward or explicitly decide I don't have the proper energy/focus for it at that time and move on to something easier.

Not to mention that MOSS is the 'simplified' way... if you don't comply you would actually have to register and file VAT in all countries separately.

Networkapp | Allround web Developer | Utrecht (The Netherlands) | ONSITE, https://networkapp.eu/

Networkapp is an app focussed around Networking at events and in communities. We are looking for a web developer that can work on both frond end backend of the customer dashboard that controls the app as well as the API and backend for the app. We currently work with: Python, Flask, SQLAlchemy, Bootstrap, jQuery.

We are a small team and there will be many opportunities to make your mark and contribute to the final product and customer experience. We expect you to work at the office in Utrecht for at least two days a week, the rest of your time can be flexible and remote.

We encourage learning and if you are interested you can extend your skills in the area of app development as well.

https://networkapp.eu/nl/vacatures/

Although I agree with the idea that Frameworks can easily make your life worse instead of better. Especially at the time the Framework moves forward to a version that is not at all compatible with what you are doing.

However, in your update you are suggesting to use Object.observe as a simple alternative to React. I looked it up and https://developer.mozilla.org/en/docs/Web/JavaScript/Referen... says it is deprecated and even removed in some browsers.

Using API's that are not widely supported and then not relying on a well supported framework to abstract them, seems to me an even worse maintenance nightmare than sticking with a Framework.

I think the assumption of the author is that the 3 hours he does work are best-case productive hours. If you work 40+ hours a week, you still have to account for all those staring-at-your screen hours, that are not contributing towards meeting the deadline.

Somewhat related: I found it is a lot easier (and natural) to estimate projects in terms of 'ideal' hours. And then just assume there are only 20 to 25 of those a week. That quite closely matches the 21 hours of the original post.