Most Windows permissions models are built around explicit "allow" Access Control Lists (ACLs) rather than "deny". NTFS (and other parts of Windows) supports setting Deny ACL's but they are not as commonly used.
The standard approach using "Allow" only permissions starts off with users having no rights at all. Then they are granted certain rights rather than being explicitly given "do or do not" states. So "Read only" is (usually) the absence the write permission. If you have two (or more) sets of permissions from two separate security principals (e.g. from your user account and a group membership or two separate groups) you are granted the result of all permissions from all principals so if any one of those has the "Write" permission then you get "Write" access even if one or more of the individual Security Principals only has "Read Only" access.
If Deny ACLS are used the same applies - if the user or any group is denied a specific right that overrides everything else.
In your case it's unlikely that Deny permissions are being used and Bob should be able to write to the folder. It may be a lot more complicated than that though.
On top of the explicit permissions on particular files\folders you have (optional) inheritance from lower levels so the effective permissions on a particular file or folder may depend on explicit permissions set at some level below (ie closer to the root) the particular object you are concerned with.
This is further complicated by the fact that Windows Shares have an entirely separate security model - shares can be set to Read only\Change or Full Control. If a share is set as Read Only then that will override file level permissions provided the user is connected using that share name. Having Change\Full Control rights does not override the underlying NTFS permissions however.
Finally there is also the standard file system "Read Only" flag. This isn't a permission as such but if it is set then nobody can change the file unless they reset the flag first.